std-unix@ut-sally.UUCP (Moderator, John Quarterman) (10/26/86)
From: seismo!allegra!phri!roy@sally.utexas.edu (Roy Smith)
Date: Sun, 19 Oct 86 20:51:49 EDT
I haven't been following this case-sensitivity discussion too
closely, so forgive me if this point has already been brought up. Imbedded
capitals are useful for separating the components of multi-word filenames
without wasting valuable characters. Consider the following:
1) UnixCaseDebate
2) unixcasedebate
3) unix_case_debate (or trivial variations like unix.case.debate)
I think most would agree that #2 is much less readable than either
of the others. Whether #1 or #3 is easier to read is in the eye of the
beholder, but consider that the former is a valid filename in 14-character
systems, while the latter is not.
All this aside, it has been stated over and over again that the job
of a standard is to agree on something which is the most compatible with
the most existing implementations. I don't know of any existing Unix
implementations that have case-insensitive filenames, so why start now?
It has already been pointed out by several people that various
layered Unix products, such as Eunice, have dealt with the problem of
enforcing (or, if you prefer, "allowing") case sensitivity with an
underlying OS that doesn't. On the other side of the coin, application
programs like Emacs provide case-insensitivity in filenames with a
case-sensitive OS underneath. Thus, the argument that having a
case-insensitive file system makes Unix more portable just doesn't hold
water.
So, what do you have? An idea that doesn't provide any added
portability, or any added capability that can't be provided by an
application, and is incompatible with most (all?) existing implementations.
Sounds like a bad idea to me.
Roy Smith, {allegra,philabs,cmcl2,sun}!phri!roy
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016
Volume-Number: Volume 7, Number 77