From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Subject: Re: [9fans] Re: blanks in file names In-reply-to: To: 9fans@cse.psu.edu Message-id: <200207110508.g6B58jI08996@dave2.dave.tj> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Date: Thu, 11 Jul 2002 01:08:44 -0400 Topicbox-Message-UUID: c90ae17c-eaca-11e9-9e20-41e7f4b1d025 If you're going to rewrite the UI programs (like ls) to print filenames in human-readable format, you'll need to make an option in each program that outputs filenames to make it output the names in human-readable or other-program-readable format ... yucky. . . - Dave Jim Choate wrote: > > > On Wed, 10 Jul 2002, Dave wrote: > > > If I had to vote a priori, blanks would certainly be a no-go for > > filenames. However, the pressure cooker has already burst, and our > > chicken is headed straight towards the ceiling. Getting rid of spaces in > > filenames is not much of an option, if we want to be able to get along > > in the wide world of non-space-restricted systems. > > Um, strictly speaking for most OS'es (and logically in general) the > 'string' that represents the filename canonicaly -should- be (usually) "" > delimited. > > In other words, > > ls filename.foo > > should really be, > > ls "filename.foo" > > or perhaps, > > ls "file/"Bill/".foo" > > The fact that the OS allows one to drop them (assuming you don't use > things like blanks in filenames) is really a courtesy of the shell > implimentation. That's where it should stay. Why the filesystem would > -ever- need the filename for internal operations would, at least to my > mind, be a major error in implimentation. Other than in 'friendly name' > situations (ie UI related) the system should be oblivious of the filename. > > If it's a valid character in the character set, it should be allowed in a > string (except for logical issues - eg printing some non-printable) should > print some sort of symbol allowing one to recognize this. This > 'conversion' should also stay strictly in the UI related code. To do > otherwise raises a host of issues about side effects and special cases w/ > regard to sting handling libraries. To not allow spaces in filenames only > makes the world more complicated. It also destroys a layer of generality, > and that is -almost always- a BAD thing. > > With respect to filenames, it's a string of -reasonably- unique (re issues > of location and such) 1's and 0's to the OS. It doesn't really 'mean' > anything to the OS::File System. It's the User::UI that it matters to. > > User::UI::OS::File System > > Leave the problem where it belongs, in the cli/shell. > > > -- > ____________________________________________________________________ > > When I die, I would like to be born again as me. > > Hugh Hefner > ravage@ssz.com www.ssz.com > jchoate@open-forge.org www.open-forge.org > > -------------------------------------------------------------------- > >