case sensitive filenames

[Moderator, John Quarterman]

From: mckenney at 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<ESC>' (where <ESC> 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 at ut-sally.UUCP> (just tell the user to type 'foobar<ESC>').

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 at 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 at 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 at sri-unix.arpa
			{pyramid,rutgers,ucbvax!hplabs}!sri-unix!mckenney

Volume-Number: Volume 7, Number 89