🚀 go-pugleaf

From: Donn Terry <donn@hpfcrn.hp.com>

>From: randall@uvaarpa.virginia.edu (Randall Atkinson)

>On an unrelated note, I will not find it acceptable or useful as a user
>to have to change the names of the verious commands specified in 1003.2
>-- in particular Donn Terry's article leaves me with the impression
>that the group has forgotten that those many of use who use these 
>tools interactively outside of shell scripts will find name changes
>unacceptable.  Yes I do use shell scripts from time to time, but
>I use the commands alone at least as often and the committee needs
>to treat that as a paramount consideration.  Creating a standard that
>won't be used is unproductive.

First of all, in these situations there is a given: your system's behaivior
(that you are used to) is different than someone else's system (that he
is used to).  If everyone agreed, there wouldn't be a need to change anything.
Its only when two implementations disagree (and clash) that the problem
even comes up.

The choice is pretty binary:

	1) Don't change the name: break scripts (and user habits)
	   for some system.  (Presume it would be yours, whatever it might
	   be, at least part of the time.) Have loads of subtle bugs.

	2) Do change them name: break everyone equally, but allow the
	   vendor to leave all old code run.  (And all your finger-macros
	   would work too.)

More important than anything else is to remember that choice 1 is guaranteed
to cause exactly the problem you are concerned about, albeit at the option
level, not at the command name level.

Changing the name lets the vendor make you happy by providing an extension
that is backwards compatible with your old habits.  You don't have the
problem you describe, presuming your vendor is at all sensitive to user
needs.

Donn Terry
(As usual, whether I say it or not, these are just my opinions.)

Volume-Number: Volume 18, Number 46