home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.19 / text0083.txt < prev    next >
Encoding:
Internet Message Format  |  1990-05-17  |  4.5 KB
  1. From: hlj@posix.COM (Hal Jespersen)
  2.  
  3. In article <1990Apr17.225128.7324@ico.isc.com> you write:
  4. From: Jeffrey S. Haemer <jsh@usenix.org>
  5.  
  6. >      1003.2:_Shell_and_Utilities
  7.  
  8. >      Even the controversial UPE is mostly codifying existing practice.
  9. >      Arguments are over places where more than one practice is widespread,
  10. >      for example, source-code control, where partisans of SCCS struggle
  11. >      with partisans of RCS.  (Actually, that's not true.  What's really
  12. >      happening is that the group's shying away from this area because
  13. >      they're worried about a struggle.  ``Tar wars'' seems to have spoiled
  14. >      the industry's appetite for making difficult decisions about conten-
  15. >      tious topics.)
  16.  
  17. This isn't really true.  We discussed the problems of another Tar War,
  18. but it didn't occur.  The group was overwhelmingly in favor of using
  19. SCCS as the superior technical solution, but SCCS has two problems:
  20.  
  21.     1.  It has a user-unfriendly interface.  This was solved by
  22.     taking the BSD "sccs" command as the main interface.
  23.  
  24.     2.  It is a complex system and no one wanted to tackle implementing
  25.     it from scratch.  Therefore, the group decided that if SCCS could
  26.     be put into the public domain, or close to it with easy source
  27.     redistribution rights, it would be appropriate.
  28.  
  29. Unfortunately, SCCS's owner chose not to "donate" its work to the working
  30. group and the world in this way.  Therefore, the WG officially dropped
  31. the whole subject and went on to other matters.  Lurking in the background
  32. was the knowledge that all this source control stuff is rather old
  33. technology anyway and new, perhaps CASE, systems would probably be a
  34. better choice on which to base future standards.  The door to standardizing
  35. this stuff is still open:  would anyone like to volunteer to start a
  36. working group, or directly ballot a document on this subject?  (I thought so.)
  37.  
  38. >      The equivalent of .1a already has a name: .2b.  Even the bad of dot
  39. >      one is mirrored here.  Truly controversial proposals are being pushed
  40. >      off to the as-yet unborn .2c, which should produce a deja vu feeling
  41. >      in those already watching .1b.
  42.  
  43. I don't know of any "controversial" proposals being pushed off to .2c.
  44. There is some I18N work that may come in at that time, but it's premature,
  45. not controversial.  Actually, no .2c (or .2b for that matter) PAR has been
  46. submitted yet.  Although .2b is a given, because clarifications and
  47. interpretations of .2 and .2a will be needed in the production of
  48. IS 9945-2, there will only be a .2c if a working group decides to form
  49. up to do it.  I'm not convinced that the UNIX command line interface
  50. is going to be interesting enough in the future to keep people charged
  51. up for new standards on it.
  52.  
  53. >      And, just as .1 sometimes shied away from real decisions, in
  54. >      order to avoid upsetting anyone, .2 occasionally reacts to vendor
  55. >      inconsistency by proposing solutions that avoid upsetting any vendor
  56. >      by penalizing all users.  As an example, the committee proposes
  57. >      requiring a C compiler (good), and naming it c89 (bad, but I com-
  58. >      plained about this loud and long last time).  An important motivation
  59. >      for the new name is that cc already invokes the K&R C compiler on many
  60. >      vendors' platforms, and specifying a flag to choose one behavior or
  61. >      the other would conflict with someone's existing implementation; any
  62. >      given letter is already preempted by some vendor.
  63.  
  64. This action only penalizes users who cannot figure out how to alias,
  65. link, or shell script themselves around the problem of accessing a command
  66. using another name (or those who don't have a system administrator or
  67. vendor to do it for them).  The problem of vendors using up the entire
  68. alphabet of option letters was real.  And your solution (not reproduced
  69. here) of simply telling everyone they had to get the ANSI C compiler
  70. when they said "cc" was simply unacceptable to too many WG members.
  71.  
  72.                     Hal Jespersen
  73.                     POSIX Software Group
  74.                     447 Lakeview Way
  75.                     Redwood City, CA 94062
  76.                     Phone:    +1 (415) 364-3410
  77.                     FAX:    +1 (415) 364-4498
  78.                     UUCP:    uunet!posix!hlj
  79.                      -or-    hlj@posix.COM
  80.  
  81.  
  82. ==========================================================================
  83. The opinions expressed in this message are my own and do not necessarily
  84. reflect those of the POSIX Working Groups or the IEEE.  To receive an
  85. official interpretation concerning an approved IEEE standard, contact the
  86. Secretary, IEEE Standards Board, P.O. Box 1331, 445 Hoes Lane, Piscataway,
  87. NJ 08855-1331.
  88.  
  89. Volume-Number: Volume 19, Number 86
  90.  
  91.