home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / mod.std.unix.v7 / text0065.txt < prev    next >
Encoding:
Internet Message Format  |  1987-06-30  |  5.3 KB
  1. From: <@SUMEX-AIM.ARPA:MRC@PANDA> (Mark Crispin)
  2. Date: Thu 16 Oct 86 23:13:06-PDT
  3. Postal-Address: 1802 Hackett Ave.; Mountain View, CA  94043-4431
  4. Phone: +1 (415) 968-1052
  5.  
  6.      I was hoping that the moderator would stay neutral in this.
  7. I encourage his subsequent neutrality.
  8.  
  9. [ The moderator is neutral.  A statement on editorial policy is
  10. forthcoming.  If you want to discuss that issue, let's do it in
  11. that channel and not this.  -mod ]
  12.  
  13.      It seems that the two sides in this issue boil down to this:
  14. . "gee, since we're defining a standard portable operating system
  15.   that isn't necessarily the present de facto Unix, let's fix
  16.   this case sensitivity cretinism"
  17. . "case sensitivity is what makes Unix better than any other
  18.   operating system, and only a cretin can't understand why this
  19.   is wonderful"
  20.  
  21.      Neither side is being very scientific.  It's reminiscent of
  22. the "how many angels can dance on the head of a pin" debates.
  23.  
  24.      Let's start by discarding the arguments which are bogus.
  25. The most glaring of these has got to be the international
  26. compatibility argument.  The only advocates of this argument seem
  27. to be pro case sensitivity Americans who have seized upon this as
  28. an argument to shore up their position without really thinking
  29. over the issue carefully.
  30.  
  31. [ Perhaps you could elaborate on why X/OPEN (a group of European
  32. computer manufacterors), for instance, should not be concerned
  33. with international compatibility?  -mod ]
  34.  
  35.      Unix does not allow arbitrary strings in filenames.  Any
  36. number of "funny" characters must be within a quoted string.  I
  37. can't say
  38.     rm foo.bar;1
  39. I have to say
  40.     rm "foo.bar;1"
  41. Guess what.  A number of foreign keyboards use those "funny"
  42. characters to be non-English glyphs.
  43.  
  44. [ The *shell* interprets certain characters, causing
  45. them to have to be quoted if they are used in file names.
  46. The file system is perfectly happy to put just about anything
  47. but the slash and null characters in filenames.  -mod ]
  48.  
  49.      I have yet to hear of any organization in Japan using kanzi
  50. or hirogana or katakana in filenames.  There are good reasons for
  51. this!  One is that there isn't a single way of representing
  52. written Japanese.  In older terminals, the high order bit when
  53. set indicated katakana (much as DEC VT220's use the high order
  54. bit for their "international characters").  Modern Japanese
  55. terminals use the JIS (Japanese Industrial Standard) system of
  56. ESCAPE followed by two bytes to define a 14 bit character.
  57. There's a minor portability problem with all those escape
  58. characters (which, of course, must be displayed in image form).
  59.  
  60. [ Perhaps someone from Japan could reply?  -mod ]
  61.  
  62.      Some German keyboards use various 7-bit glyphs (I believe
  63. "@" is umlaut-a) for their umlauts and ess-tset.  Or, there's the
  64. VT220 system.  I just tried creating a file called Goethestrasse
  65. (using umlaut-o for "oe" and ess-tset for "ss") on my local Unix
  66. system using my VT220 clone.  It made "GVthestra_e", the 7-bit
  67. form.  Dare I mention that in German, only nouns (and the first
  68. word in a sentence) are capitalized?
  69.  
  70. [ What is the "it" that made it?  How did you create it?
  71. What were the character codes you tried to use for the characters?
  72. Don't forget the capitalization of sharp s problem:  it's
  73. one character in lower case but two (SS) in upper case.  -mod ]
  74.  
  75.      The point is that Unix does *not* support international
  76. character sets in filenames.  It supports 7-bit USASCII.  So
  77. let's leave that issue to rest.
  78.  
  79. [ There is strong interest on the part of a number of UNIX vendors
  80. and users to make UNIX support international character sets in
  81. a number of areas.  Anything that ties the filesystem or anything
  82. else in the system to USASCII is not a step in a direction they want.
  83. The file system at the moment supports uninterpreted strings of
  84. bytes as file names, with the exception of /, null character,
  85. names consisting solely of . and .., and those systems that
  86. too helpfully zero the high order bit (4.3BSD, if I'm not
  87. mistaken).  -mod ]
  88.  
  89.      I haven't yet heard of any serious use of full 8-bit bytes
  90. for filenames on any other operating system, which, if you are
  91. serious about supporting international character sets, you must
  92. do.  There's this small problem of getting 8-bit (as opposed to
  93. 7-bit) ASCII through various pieces of hardware and networks
  94. which think that the high order bit is parity...
  95.  
  96.      Can we now leave that particular argument to rest?
  97.  
  98. [ The Japanese seem to manage the eight bit problem on UNIX,
  99. as modified both there and by AT&T to support the Japanese
  100. language.  Most anyone who uses EMACS has the same problem,
  101. and many of them seem to manage.  -mod ]
  102.  
  103.      Nobody has really answered the criticism that case
  104. sensitivity is poor human engineering.
  105.  
  106. [ See Barry Shein's article, <6011@ut-sally.UUCP>.  -mod ]
  107.  
  108.   Some people may disagree.
  109. The same people may also feel that single character switches are
  110. good human engineering.  Well, a lot of us who haven't been Unix
  111. junkies for the past 15 years seem to feel otherwise.  The fact
  112. that there is a controversy over the human engineering aspects of
  113. a facility should suffice to indicate that there is a problem!
  114.  
  115.      Let's discuss these classes of issues.
  116.  
  117. [ If you have a survey that shows that most people find case insensitivity
  118. easier to deal with, please present it.  If not, please refrain from
  119. proof by character assassination.  -mod ]
  120.  
  121. -- Mark --
  122. -------
  123.  
  124. Volume-Number: Volume 7, Number 66
  125.  
  126.