Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!decvax!ucbvax!ucbcad!nike!rutgers!seismo!ut-sally!std-unix From: std-unix@ut-sally.UUCP (Moderator, John Quarterman) Newsgroups: mod.std.unix Subject: Re: case sensitive filenames Message-ID: <6107@ut-sally.UUCP> Date: Sun, 26-Oct-86 01:19:05 EST Article-I.D.: ut-sally.6107 Posted: Sun Oct 26 01:19:05 1986 Date-Received: Sun, 26-Oct-86 07:17:13 EST References: <5860@ut-sally.UUCP> Organization: IEEE P1003 Portable Operating System for Computer Environments Committee Lines: 77 Approved: jsq@sally.utexas.edu From: mckenney@sri-unix.arpa (Paul E. McKenney) Date: Thu, 23 Oct 86 17:27:21 pdt Organization: SRI, Menlo Park, CA. Ok, how about a compromise proposal? Keep roughly the same case-sensitivity in the kernel interface that exists now. This means that (for example) 'unlink("abc")' and 'unlink("ABC")' will remove two different files. Keep the normal shell interface for filenames. This means that (again, for example) 'rm abc' and 'rm ABC' will again remove two different files. Make escape completion case insensitive. (Escape completion is used in some versions of BSD 4.x csh, perhaps elsewhere also. It allows a user to type the first part of a filename (or command name) and then hit ESC. The system will complete the filename as best it can. If it cannot unambiguously determine the filename from the part given by the user, it will beep after having supplied as much of the filename as it can without problems with ambiguity. There is also usually a feature that allow the user to display all filenames that match what he has typed so far -- control-D serves this function in some variants of BSD 4.2 csh.) In other words, if a user types 'rm abc' (where represents the ESC key), and there is a file named 'ABC', and there is no other file that matches the pattern '[aA][bB][cC]', the shell (-not- the kernel) will backspace over the 'abc' and overwrite it with 'ABC' so that the command line will look as if the user had typed 'rm ABC'. The user may then hit RETURN if he wishes to execute the command, or he may further edit the command line (using his usual backspace/delete, etc. characters). This escape-mapping facility should be supplied in a library routine so that application programs can easily act the same way. It would be nice if such a function could work with keywords, hostnames, etc. as well as filenames. This proposal has the following advantages: o It does not impact existing software (addition of the case-insensitive ESC does not add any functionality, it just makes it easier on users). o It answers Mark Horton's 'filename-over-the-phone' problem <6049@ut-sally.UUCP> (just tell the user to type 'foobar'). o It allows users from a case-insensitive environment a helpful tool to ease their transition (let's face it -- if it is different than whatever you are used to, it ain't friendly -- regardless of whether you are used to case sensitivity, case insensitivity, or hieroglyphics). o Removes the need for millions and millions of 'upper()' calls in application code mentioned by Dan Libes <5959@ut-sally.UUCP> (although the additional code to do good escape-completion is far from trivial!). o Removes the need for 'isfsense()' or 'isflegal()' (Chris Lent, <5971@ut-sally.UUCP>) since all implementations could use the same definition of legal characters in a pathname. Note that 'isflegal()' is still useful for programs that are trying to be portable across different operating systems. This proposal leaves the following two issues unresolved: o Whether the eighth bit on characters within a filename should be significant. The developers of BSD 4.[23] must have had some good reason for making it insignificant, but the only reason that comes to mind is that most terminals cannot easily specify the eighth bit (just like some older terminals cannot easily specify lower case!). o Whether there should be some escaping mechanism to allow slash ("/") and ASCII NUL in a filename. I cannot think of a reason for allowing this that seems worth the trouble -- any comments? Paul E. McKenney mckenney@sri-unix.arpa {pyramid,rutgers,ucbvax!hplabs}!sri-unix!mckenney Volume-Number: Volume 7, Number 89