home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.18 / text0045.txt < prev    next >
Encoding:
Internet Message Format  |  1990-03-18  |  1.9 KB
  1. From: Donn Terry <donn@hpfcrn.hp.com>
  2.  
  3. >From: randall@uvaarpa.virginia.edu (Randall Atkinson)
  4.  
  5. >On an unrelated note, I will not find it acceptable or useful as a user
  6. >to have to change the names of the verious commands specified in 1003.2
  7. >-- in particular Donn Terry's article leaves me with the impression
  8. >that the group has forgotten that those many of use who use these 
  9. >tools interactively outside of shell scripts will find name changes
  10. >unacceptable.  Yes I do use shell scripts from time to time, but
  11. >I use the commands alone at least as often and the committee needs
  12. >to treat that as a paramount consideration.  Creating a standard that
  13. >won't be used is unproductive.
  14.  
  15. First of all, in these situations there is a given: your system's behaivior
  16. (that you are used to) is different than someone else's system (that he
  17. is used to).  If everyone agreed, there wouldn't be a need to change anything.
  18. Its only when two implementations disagree (and clash) that the problem
  19. even comes up.
  20.  
  21. The choice is pretty binary:
  22.  
  23.     1) Don't change the name: break scripts (and user habits)
  24.        for some system.  (Presume it would be yours, whatever it might
  25.        be, at least part of the time.) Have loads of subtle bugs.
  26.  
  27.     2) Do change them name: break everyone equally, but allow the
  28.        vendor to leave all old code run.  (And all your finger-macros
  29.        would work too.)
  30.  
  31. More important than anything else is to remember that choice 1 is guaranteed
  32. to cause exactly the problem you are concerned about, albeit at the option
  33. level, not at the command name level.
  34.  
  35. Changing the name lets the vendor make you happy by providing an extension
  36. that is backwards compatible with your old habits.  You don't have the
  37. problem you describe, presuming your vendor is at all sensitive to user
  38. needs.
  39.  
  40. Donn Terry
  41. (As usual, whether I say it or not, these are just my opinions.)
  42.  
  43. Volume-Number: Volume 18, Number 46
  44.  
  45.