From mboxrd@z Thu Jan 1 00:00:00 1970 Message-Id: <200206011654.RAA24007@cthulhu.dircon.co.uk> Subject: Re: [9fans] spaces in filenames In-Reply-To: from Michael Baldwin at "May 31, 2002 11:35:47 pm" To: 9fans@cse.psu.edu From: Digby Tarvin MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Date: Sat, 1 Jun 2002 17:54:42 +0100 Topicbox-Message-UUID: a40fd422-eaca-11e9-9e20-41e7f4b1d025 I always rather liked the old Unix approach of the Kernel allowing anything for which there was no compelling technical reason to forbid. For file names, that used to be (in the old Bell Labs days) any sequence of up to 14 bytes, excluding '/' and the NULL used as terminator (both in the directory entry and the strings passed in system calls). The subsequent relaxation of the length restriction was certainly a good thing, but otherwise I was quite happy with the status quo. As to to desirability of actually using file names with non-printable characters - that is certainly questionable. I would prefer to have a conservative file nameing scheme used in the 'standard' distribution, refraining from unnecessary use of unprintable ascii in file names. But I would no more have the operating system enforce it than I would have the system dictate what bytes appear in a text file. Most objections to flexible file nameing seem to be the result of syntactic limitations of the shell which make it difficult to remove or rename strangely named files when created accidentaly. It was never difficult to to get rid of them by writing a one line C program. As I recall, Unix 6th edition came with a 'dsw' (Delete from SWitches) command to help remove files with funny names. Perhaps something similar is needed. I do recall once amusing myself as a student arranging to be allocated inode '0407' for a directory so that with appropriate choice of file name I could create a directory which would also be an executable program. The most compelling reason I can think of for disliking artificial restrictions on file names (and also case insensitive file names) is that it is so inconvenient when importing file systems from, or sharing filesystems with, less restrictive operating systems. Admittedly you are stuck either way with differences in file name case sensitivity, but I would rather have the problem of not finding a file because of a case mis-match than over-writing a file due to case insensitivity. Although I could probably come up with a scheme whereby files were stored in a case insensitive way, but directories could be searched with a 'case insensitive' option which would return the first match - as a form of wildcarding. It would then be an application issue weather you were protected from accidentally creating multiple files differing only in case. If your file system was case insensitive, a workaround to simulate case sensitivity would be much more difficult. One final comment - on the OS-9 operating system (not to be confused with with MAC OS-9, which it predates by about 20 years...) there is quite a convenient facility which allows file nameing restrictions to be varied dynamically. The default disallows, for instance, spaces in file names. But as a super user, if I want to unpack a tar file which contains such names, I can temporarily redefine the file name validation parameters, unpack the archive, and then revert to normal conventions. This gives the flexibility without the danger of accidental creation of funny files. Perhaps if this facility were available on a per user basis, then those that know what they are doing could relax restrictions when there was a good reason, and others would be protected from mistakes. Regards, DigbyT > really, what is the big deal with spaces in filenames? yeah, there are > some file formats here and there, and some shell files that maybe aren't > so careful, so it's not a cakewalk, but it isn't some Big Huge Problem. > using shells like rc that manage lists of string works quite well; if > you need a list of files use "ls" not "echo"; if you really want to use > the output of a command with backquote, set ifs to \t\n. > > geoff talks about how maddening it is to use filenames with spaces on > mac os x. i use mac os x too, and have lots of files with spaces, and i > use quotes on the occasion that i refer to them in the shell. i haven't > noticed any "problem" that would cause me to go mad, and everything > works just fine from the shell and the gui for me. i send spacey > filenames to web sites, attach/detach them from mail messages, move them > about, and things work. what am i missing? now that i can use spaces, > i kinda like using space instead of _ in names -- easier to type and > easier to read. why banish the poor lowly space character? so call me > a communist for my radical views. > > the only problem i've had with spaces is getting to spacey files on > windows and unix from plan 9 and inferno. i took out the space > restriction in inferno and things work swimmingly. yeah, i know there > are gotchas here and there, but they really haven't been an issue. i > much prefer the ability to manipulate files to the odd gotcha. > > oh, the non-printable range also includes 7F, so it's really 00-1F and > 7F-9F that are restricted. it does seem to be a Good Thing that \t and > \n are not allowed, leaving them usable as delimiters. unix lets you > create such files, but they definitely seem rare, and it is a bit harder > to do from a gui. who cares if they don't work right. but leave poor > space alone. > -- Digby R. S. Tarvin digbyt@acm.org http://www.cthulhu.dircon.co.uk