home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / mod.std.unix.v7 / text0075.txt < prev    next >
Encoding:
Internet Message Format  |  1987-06-30  |  8.2 KB
  1. From: guy@sun.com (Guy Harris)
  2. Date: Mon, 20 Oct 86 10:49:33 PDT
  3.  
  4. Responses to a couple of messages:
  5.  
  6. >From Mark Horton:
  7.  
  8. > Any solution to this problem must be in the kernel, or possibly
  9. > in libc underneath such subroutines as open, unlink, and chmod, (if you
  10. > have shared libraries or full source to recompile) or it won't work all
  11. > the time.
  12.  
  13. Any solution to this problem must be applied to operating systems other than
  14. UNIX.  As John Bruner pointed out, mandating case-insensitivity will only
  15. have the effect of removing UNIX from the list of standard-conforming
  16. systems.  Changing the semantics of file names at this late date is unlikely
  17. to meet with approval from many UNIX vendors and users.  For one thing, what
  18. are you going to do about directories that contain files named, say,
  19. "makefile" and "Makefile" (yes, they exist)?  You may feel that having
  20. directories like this is a mistake, but declaring them to be a mistake isn't
  21. going to make them go away.
  22.  
  23. There seem to be two issues here:
  24.  
  25. 1) Should POSIX mandate case-sensitivity?
  26.  
  27. 2) Should UNIX be changed to be case-insensitive if POSIX doesn't mandate
  28. case-sensitivity?
  29.  
  30. These are rather separate issues.  A case can be made that POSIX should not
  31. mandate case-sensitivity.  Applications must then not depend on
  32. case-sensitivity.  This will affect programs that create files with names
  33. other than those provided by the user.  It could also affect programs that
  34. *read* directories, since they'd have to know that "foobar" and "FoOBaR"
  35. refer to the same file.
  36.  
  37. I see great difficulty in changing UNIX to be case-insensitive, however.  It
  38. certainly wouldn't pose any great *implementation* difficulties, but I would
  39. not like to bet that no user or program would be greatly affected.
  40.  
  41. >From Mark R. Crispin:
  42.  
  43. >     It seems that the two sides in this issue boil down to this:
  44. > . "gee, since we're defining a standard portable operating system
  45. >   that isn't necessarily the present de facto Unix, let's fix
  46. >   this case sensitivity cretinism"
  47. > . "case sensitivity is what makes Unix better than any other
  48. >   operating system, and only a cretin can't understand why this
  49. >   is wonderful"
  50.  
  51. Not really.  A POSIX standard that does not *mandate* case-sensitivity need
  52. not *forbid* it.  And I have seen *no* arguments that "case sensitivity is
  53. what makes UNIX better than any other operating system."
  54.  
  55. >      Let's start by discarding the arguments which are bogus.
  56. > The most glaring of these has got to be the international
  57. > compatibility argument.  The only advocates of this argument seem
  58. > to be pro case sensitivity Americans who have seized upon this as
  59. > an argument to shore up their position without really thinking
  60. > over the issue carefully.
  61.  
  62. Well, it may seem that way, but it isn't.  I admit to being a United States
  63. citizen, but I am not unreservedly pro-case-sensitivity.  I see the merits
  64. to both sides of the argument, but I see more problems with
  65. case-insensitivity than with case-sensitivity.
  66.  
  67. >      Unix does not allow arbitrary strings in filenames.  Any
  68. > number of "funny" characters must be within a quoted string.  I
  69. > can't say
  70. >     rm foo.bar;1
  71. > I have to say
  72. >     rm "foo.bar;1"
  73. > Guess what.  A number of foreign keyboards use those "funny"
  74. > characters to be non-English glyphs.
  75.  
  76. As the moderator pointed out, the shell, not the operating system,
  77. interprets these funny characters.  Applications need not get file names
  78. passed as arguments from the shell.  The office automation system we
  79. developed at CCI had its own shell, which did no parsing of path names
  80. whatsoever; the only characters it forbade were the slash and the null
  81. character (because they are not allowed in UNIX filenames) and those
  82. characters its forms package didn't allow you to type in (because we never
  83. got around to changing it to do so).  I frequently used file names
  84. containing blanks within this application, even though it made it
  85. inconvenient to manipulate those files using commands typed at the UNIX
  86. shell.
  87.  
  88. >      I have yet to hear of any organization in Japan using kanzi
  89. > or hirogana or katakana in filenames.
  90.  
  91. I have a document in front of me from ASCII Corporation in Japan, describing
  92. changes made to 4.2BSD to support Kanji and Kana.  It says:
  93.  
  94.     It is possible to create a file whose name contains Kana and/or
  95.     Kanji characterss, since the file system and Kanji version of
  96.     the shell support it.  However, we don't recommend such filenames,
  97.     becasue it is impossible to handle such files from ASCII terminals.
  98.  
  99. The argument used against it would not apply if, for example, no terminals
  100. attached to the machine were ASCII terminals and the site didn't expect to
  101. export these files to machines with only ASCII terminals attached.  The
  102. developers of it may be coming from a more "traditional" UNIX environment,
  103. where you have many ASCII terminals attached to the machine and where you
  104. frequently exchange files with other sites not running the same hardware and
  105. software that you are running.  In an office environment, it may be possible
  106. to provide everyone with a Kanji/Kana terminal, and it may not be as
  107. important to worry about exchanging file with some random development
  108. machine in the United States.
  109.  
  110. >   There are good reasons for
  111. > this!  One is that there isn't a single way of representing
  112. > written Japanese.  In older terminals, the high order bit when
  113. > set indicated katakana (much as DEC VT220's use the high order
  114. > bit for their "international characters").  Modern Japanese
  115. > terminals use the JIS (Japanese Industrial Standard) system of
  116. > ESCAPE followed by two bytes to define a 14 bit character.
  117.  
  118. The system they describe uses "Shift JIS" code for Kanji, and supports both
  119. terminals that use this code and the regular JIS code for Kanji; it does
  120. code conversion between the codes for JIS-Kanji terminals.
  121.  
  122. >      Some German keyboards use various 7-bit glyphs (I believe
  123. > "@" is umlaut-a) for their umlauts and ess-tset.  Or, there's the
  124. > VT220 system.  I just tried creating a file called Goethestrasse
  125. > (using umlaut-o for "oe" and ess-tset for "ss") on my local Unix
  126. > system using my VT220 clone.  It made "GVthestra_e", the 7-bit
  127. > form.
  128.  
  129. The latter sounds like ISO Latin Alphabet No. 1; "umlaut-O" has the hex code
  130. D6 and capital V has the code 56; 56 hex + 80 hex is D6 hex.  (I believe DEC
  131. recommended the VT220 code set to ISO for standardization.)
  132.  
  133. >   Dare I mention that in German, only nouns (and the first
  134. > word in a sentence) are capitalized?
  135.  
  136. The same is true of English; so what?
  137.  
  138. >      The point is that Unix does *not* support international
  139. > character sets in filenames.  It supports 7-bit USASCII.  So
  140. > let's leave that issue to rest.
  141.  
  142. As the moderator pointed out, this is not the case.  The kernel supports all
  143. characters except slash and the null character, except for the 4.[23]BSD
  144. kernel which (too helpfully) refuses to create files with characters in
  145. their name that have the eighth bit set.  Certain UNIX utilities do not
  146. handle 8-bit characters; this is not, however, an intrinsic characteristic
  147. of the UNIX system.  I would ask European and Asian customers what they
  148. wanted the UNIX system to do about character sets other than 7-bit USASCII
  149. before I casually dismissed the possibility of supporting them.
  150.  
  151. >      I haven't yet heard of any serious use of full 8-bit bytes
  152. > for filenames on any other operating system, which, if you are
  153. > serious about supporting international character sets, you must
  154. > do.  There's this small problem of getting 8-bit (as opposed to
  155. > 7-bit) ASCII through various pieces of hardware and networks
  156. > which think that the high order bit is parity...
  157.  
  158. Not all such pieces of hardware have this limitation.  The paper from ASCII
  159. Corporation simply says "Kana and Kanji terminals must be set up to use 8
  160. bit no parity mode."  If other terminals use a 7-bit encoding of an 8-bit
  161. data stream, the terminal driver can do code translation transparently to
  162. the rest of the system.
  163.  
  164. The fact that most OSes haven't solved these problems, and don't provide for
  165. full 8-bit characters in file names, doesn't mean there is no demand for
  166. full 8-bit characters in file names.  The users in non-English-speaking
  167. countries may just have learned to get around this problem, and either use
  168. English-language file names or approximate their native spelling in file
  169. names.
  170.  
  171. Volume-Number: Volume 7, Number 76
  172.  
  173.