home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / mod.std.unix.v7 / text0088.txt < prev    next >
Encoding:
Internet Message Format  |  1987-06-30  |  3.6 KB
  1. From: mckenney@sri-unix.arpa (Paul E. McKenney)
  2. Date: Thu, 23 Oct 86 17:27:21 pdt
  3. Organization: SRI, Menlo Park, CA.
  4.  
  5. Ok, how about a compromise proposal?
  6.  
  7. Keep roughly the same case-sensitivity in the kernel interface that exists
  8. now.  This means that (for example) 'unlink("abc")' and 'unlink("ABC")' will
  9. remove two different files.
  10.  
  11. Keep the normal shell interface for filenames.  This means that (again, for
  12. example) 'rm abc' and 'rm ABC' will again remove two different files.
  13.  
  14. Make escape completion case insensitive.  (Escape completion is used in some
  15. versions of BSD 4.x csh, perhaps elsewhere also.  It allows a user to
  16. type the first part of a filename (or command name) and then hit
  17. ESC.  The system will complete the filename as best it can.  If it cannot
  18. unambiguously determine the filename from the part given by the user, it
  19. will beep after having supplied as much of the filename as it can without
  20. problems with ambiguity.  There is also usually a feature that allow the
  21. user to display all filenames that match what he has typed so far --
  22. control-D serves this function in some variants of BSD 4.2 csh.)
  23.  
  24. In other words, if a user types 'rm abc<ESC>' (where <ESC> represents the
  25. ESC key), and there is a file named 'ABC', and there is no other file that
  26. matches the pattern '[aA][bB][cC]', the shell (-not- the kernel) will
  27. backspace over the 'abc' and overwrite it with 'ABC' so that the command
  28. line will look as if the user had typed 'rm ABC'.  The user may then
  29. hit RETURN if he wishes to execute the command, or he may further edit
  30. the command line (using his usual backspace/delete, etc. characters).
  31.  
  32. This escape-mapping facility should be supplied in a library routine so that
  33. application programs can easily act the same way.  It would be nice if such
  34. a function could work with keywords, hostnames, etc. as well as filenames.
  35.  
  36. This proposal has the following advantages:
  37.  
  38. o    It does not impact existing software (addition of the case-insensitive
  39.     ESC does not add any functionality, it just makes it easier on users).
  40.  
  41. o    It answers Mark Horton's 'filename-over-the-phone' problem
  42.     <6049@ut-sally.UUCP> (just tell the user to type 'foobar<ESC>').
  43.  
  44. o    It allows users from a case-insensitive environment a helpful tool
  45.     to ease their transition (let's face it -- if it is different than
  46.     whatever you are used to, it ain't friendly -- regardless of whether
  47.     you are used to case sensitivity, case insensitivity, or hieroglyphics).
  48.  
  49. o    Removes the need for millions and millions of 'upper()' calls in
  50.     application code mentioned by Dan Libes <5959@ut-sally.UUCP>
  51.     (although the additional code to do good escape-completion is far
  52.     from trivial!).
  53.  
  54. o    Removes the need for 'isfsense()' or 'isflegal()' (Chris Lent,
  55.     <5971@ut-sally.UUCP>) since all implementations could use the same
  56.     definition of legal characters in a pathname.  Note that 'isflegal()'
  57.     is still useful for programs that are trying to be portable across
  58.     different operating systems.
  59.  
  60. This proposal leaves the following two issues unresolved:
  61.  
  62. o    Whether the eighth bit on characters within a filename should be
  63.     significant.  The developers of BSD 4.[23] must have had some good
  64.     reason for making it insignificant, but the only reason that comes
  65.     to mind is that most terminals cannot easily specify the eighth bit
  66.     (just like some older terminals cannot easily specify lower case!).
  67.  
  68. o    Whether there should be some escaping mechanism to allow slash ("/")
  69.     and ASCII NUL in a filename.  I cannot think of a reason for allowing
  70.     this that seems worth the trouble -- any comments?
  71.  
  72.  
  73.             Paul E. McKenney
  74.             mckenney@sri-unix.arpa
  75.             {pyramid,rutgers,ucbvax!hplabs}!sri-unix!mckenney
  76.  
  77. Volume-Number: Volume 7, Number 89
  78.  
  79.