home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / mod.std.unix.v7 / text0076.txt < prev    next >
Encoding:
Internet Message Format  |  1987-06-30  |  1.9 KB
  1. From: seismo!allegra!phri!roy@sally.utexas.edu (Roy Smith)
  2. Date: Sun, 19 Oct 86 20:51:49 EDT
  3.  
  4.     I haven't been following this case-sensitivity discussion too
  5. closely, so forgive me if this point has already been brought up.  Imbedded
  6. capitals are useful for separating the components of multi-word filenames
  7. without wasting valuable characters.  Consider the following:
  8.  
  9.     1) UnixCaseDebate
  10.     2) unixcasedebate
  11.     3) unix_case_debate (or trivial variations like unix.case.debate)
  12.  
  13.     I think most would agree that #2 is much less readable than either
  14. of the others.  Whether #1 or #3 is easier to read is in the eye of the
  15. beholder, but consider that the former is a valid filename in 14-character
  16. systems, while the latter is not.
  17.  
  18.     All this aside, it has been stated over and over again that the job
  19. of a standard is to agree on something which is the most compatible with
  20. the most existing implementations.  I don't know of any existing Unix
  21. implementations that have case-insensitive filenames, so why start now?
  22.  
  23.     It has already been pointed out by several people that various
  24. layered Unix products, such as Eunice, have dealt with the problem of
  25. enforcing (or, if you prefer, "allowing") case sensitivity with an
  26. underlying OS that doesn't.  On the other side of the coin, application
  27. programs like Emacs provide case-insensitivity in filenames with a
  28. case-sensitive OS underneath.  Thus, the argument that having a
  29. case-insensitive file system makes Unix more portable just doesn't hold
  30. water.
  31.  
  32.     So, what do you have?  An idea that doesn't provide any added
  33. portability, or any added capability that can't be provided by an
  34. application, and is incompatible with most (all?) existing implementations.
  35. Sounds like a bad idea to me.
  36.  
  37. Roy Smith, {allegra,philabs,cmcl2,sun}!phri!roy
  38. System Administrator, Public Health Research Institute
  39. 455 First Avenue, New York, NY 10016
  40.     
  41.  
  42.  
  43. Volume-Number: Volume 7, Number 77
  44.  
  45.