home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 October / usenetsourcesnewsgroupsinfomagicoctober1994disk2.iso / std_unix / volume.18 / text0026.txt < prev    next >
Encoding:
Internet Message Format  |  1990-03-18  |  2.0 KB
  1. From: Donn Terry <donn@hpfcrn.hp.com>
  2.  
  3. Although I'm not directly involved (I'm not an officer of 1003.*2*), I have
  4. been involved in the discussion of the name change.
  5.  
  6. I'm talking strictly personally here.
  7.  
  8. The problem is that the "c compiler" (and a few other) commands need to
  9. have options.  It turns out that ALL the option letters are used by some
  10. vendor or other (not all vendors use all letters (many come close) but
  11. across even a small set, all are used).  
  12.  
  13. The usages conflict.  When the standard is completed, SOMEBODY is going
  14. to have to be broken, somehow.  Thus, the name was changed to get a
  15. clean option-letter namespace for the standard, so it could have option
  16. letters at all.
  17.  
  18. I agree it will be a nuisance, but the question boils down to which do 
  19. you break:
  20.  
  21.     Existing makescripts (etc.) because the option letters changed
  22.     to conform to the standard.
  23.  
  24.     New (or at least revised) standard-conforming makescripts, (given
  25.     that none exist now.)  In either case, existing ones would have to
  26.     be rewritten to be standard conformant.
  27.  
  28. Backwards compatability was chosen, and the name changed.  (That is,
  29. vendors will continue to ship using the old name, and everything works.
  30. Only when the user wishes to change to standard-conformant does he have
  31. to do anything.   Reality says that virtually no extant application would
  32. be 100% conforming given either choice.)
  33.  
  34. (Out comes the axe to grind.)
  35.  
  36. I have been trying, so-far unsuccessfully, to get 1003.2 to reserve a
  37. namespace to the vendors for options for these commands (at least) so
  38. that when the standard is revised, we don't have the same problem.
  39. The vendors can't be expected not to use additional options.  They
  40. also can't be expected to use the same ones for everything.  Some data
  41. indicates that the problem is starting to develop already.
  42.  
  43. It should be possible to keep this to a one-time cost, but not if I 
  44. don't get support in my (so-far Quixotic) quest to keep it one-time.
  45.  
  46. Donn Terry
  47. HP, Ft. Collins.
  48.  
  49. I speak only for myself in this.  Not for either HP or as a POSIX officer.
  50.  
  51.  
  52. Volume-Number: Volume 18, Number 27
  53.  
  54.