home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / mod.std.unix.v7 / text0066.txt < prev    next >
Encoding:
Internet Message Format  |  1987-06-30  |  3.7 KB

  1. From: cbosgd!cbosgd.ATT.COM!mark@ucbvax.berkeley.edu (Mark Horton)
  2. Date: Fri, 17 Oct 86 11:20:32 edt
  3. Organization: AT&T Medical Information Systems, Columbus
  4.  
  5. Don Provan raises some interesting questions about foreign languages.
  6. In general, I think we know how to do a case insensitive comparison
  7. appropriately, by extending a function (I think it's called strcoll,
  8. but I don't have my X3J11 draft handy) defined in ANSI C; the function
  9. is like strcpy, but the destination buffer gets a translation of the
  10. string that will collate properly when a lexicographic comparison like
  11. strcmp is used.  If we extend this function to also translate to one
  12. case (as appropriate) and allow each country to define its own function,
  13. it's technically possible to ignore case.  Whether it's fast enough for
  14. the UNIX filesystem is unclear, although this problem is not restricted
  15. to UNIX.
  16.  
  17. I think it would be interesting to hear what other, case-insensitive
  18. operating systems do about these issues.  What do MS DOS, or VM/CMS,
  19. or VMS, or whatever, do with their case insensitive file names in
  20. Europe, or Japan, or whereever?
  21.  
  22. If the answer is that file names are restricted to use the same character
  23. set as in the USA, and that extra letters are disallowed, then we need to
  24. know how well this is accepted by the users on other systems.  Maybe it's
  25. good enough.  Do users in other countries often create files whose names
  26. contain extra letters?  If they try, does the shell get in the way if their
  27. letter happens to be "|", for example?
  28.  
  29. If the answer is that other operating systems have forced other countries
  30. to put up with Americanisms, and that POSIX is an opportunity to break new
  31. ground by handling other languages properly, then by all means let's do it
  32. right.  This might require 8 bit characters in file names, for example.
  33.  
  34. Incidently, I've seen it claimed here that UNIX allows arbitrary byte
  35. streams in file names.  Perhaps this is the intent, but in reality the
  36. UNIX filesystem is far from a transparent path.  There are lots of
  37. restrictions, some of which are:
  38.  
  39.     The slash character is special.
  40.     The null character is special.
  41.     Sequences of more than 14 chars not containing a slash are
  42.         either illegal or only significant to 14 chars or
  43.         significant to 256 chars, depending on the version of UNIX.
  44.     Characters with the 8th bit turned on are not allowed.
  45.     Since many commands take names beginning with "-" as flags,
  46.         file names beginning with "-" don't always work.
  47.     Since the shell treats many of the punctuation characters
  48.         specially, file names containing space, #, $, &, *, (, ),
  49.         [, ], ;, ', ", \, |, <, >. and ? do not always work
  50.         properly.  Even if you quote them, the shell strips
  51.         off the quotes, so that if multiple layers of shell
  52.         are involved (for example, uux) it still fails.
  53.  
  54. Because some of these problems only affect certain uses of the filesystem
  55. (whether or not you go through the shell, whether or not you're going
  56. through a command that takes arguments) it's not unusual for casual users
  57. to create a file and then have trouble using, renaming, or even removing it.
  58. I recall that removing a file whose 8th bit has been set is a frequent topic
  59. on net.unix.
  60.     
  61. If the filesystem were really transparent, the designers of /proc would
  62. not have had to encode process ID's in ASCII digits, they could have
  63. directly used the binary representation.
  64.  
  65. It's for these reasons that I feel that a conservative UNIX user should
  66. restrict themselves to certain "reasonable" filename conventions; basically
  67. using only lower case letters, digits, and a few save punctuation characters
  68. such as . and - in their filenames.  Just because it's possible to put a
  69. space in a file name doesn't make it a good idea.
  70.  
  71.     Mark
  72.  
  73. Volume-Number: Volume 7, Number 67
  74.  
  75.