Path: utzoo!utgpu!attcan!uunet!auspex!guy
From: guy@auspex.UUCP (Guy Harris)
Newsgroups: comp.unix.wizards
Subject: Re: Echo
Keywords: predictability, implementation-dependence, buggy, Virus !
Message-ID: <726@auspex.UUCP>
Date: 15 Dec 88 21:06:08 GMT
References: <6557@june.cs.washington.edu> <14799@mimsy.UUCP> <656@root44.co.uk> <594@mks.UUCP> <1309@ucsd.EDU> <364@skep2.ATT.COM>
Reply-To: guy@auspex.UUCP (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 52

>Serious half of the discussion - I think there's a need for
>a pair of options to echo - one forcing old BSD behavior,
>one forcing System V / ksh behavior,

Err, umm, what is "ksh behavior"?  The "ksh" with which I'm familiar
defines "echo" as an alias for "print" with some options; in older
version, whether the options select V7 behavior or S5 behavior is
conditionalized on whether "ksh" is built for a V7/BSD or S5-style
system, and in more recent versions exhibits the allegedly
"brain-damaged" behavior of choosing which options based on how PATH is
set up.... 

>with the option of passing it as an environment variable.

"echo" is just one of a set of commands whose behavior differs between
different versions of UNIX (often different versions of AT&T UNIX, e.g. 
V7 and S3/S5).  Is the intent that this environment variable choose the
behavior for all of those commands - in which case PATH is the most
straightforward such environment variable for the commands implemented
as programs or shell scripts, since you can put the different versions
in different directories - or is the intent that this environment
variable choose *only* the behavior for "echo"?

In the latter case, what is the reason why one would select a particular
behavior?  If you want a V7/BSD-compatible or S3/S5-compatible
environment, selecting only the behavior of "echo" won't give it to you.
If you have some shell script that happens to depend on a particular
behavior of "echo", but not of any other command, a cleaner way of doing
it is to provide a flag to "echo" (as I think V8 does) or to provide a
command like "print" (as "ksh" does).

>Basing the behavior of echo on whether /usr/ucb precedes usr/bin/ in
>$PATH is a seriously brain-damaged approach, prone to encouraging
>people to put lines like
>	PATH=/usr/ucb:/bin:/usr/bin ; export PATH
>in their code (I really *hate* this in shar files!)

Explicitly setting PATH in a shell script is generally a Good Idea; it
prevents you from getting "unpredictable behavior" when users muck with
their PATH.

If "/usr/ucb" doesn't exist on your system, setting PATH as specified in
your example doesn't hurt anything.  If it does exist, and the script
depends on the "/usr/ucb"-flavor behavior of a command that is present
in different flavors and "/usr/ucb" and elsewhere, it actually
*helps*....

In the long term, it would be nice if some form of behavior sufficiently
usable by shell script writers were provided, and the older
"compatibility" behavior phased out, so that some of the "problem"
commands ("echo" and "tr", to name two) cease being problems.  Perhaps,
with luck, 1003.2 will help this happen.