Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site utcs.uucp
Path: utzoo!utcs!geoff
From: geoff@utcs.uucp (Geoff Collyer)
Newsgroups: net.unix-wizards
Subject: Re: Please do NOT use "/bin/test" as a command name
Message-ID: <1023@utcs.uucp>
Date: Mon, 9-Dec-85 15:39:13 EST
Article-I.D.: utcs.1023
Posted: Mon Dec  9 15:39:13 1985
Date-Received: Mon, 9-Dec-85 15:53:35 EST
References: <313@bdaemon.UUCP> <13400016@mirror.UUCP> <1016@sdcsla.UUCP> <1019@utcs.uucp> <1747@dciem.UUCP>
Organization: University of Toronto - General Purpose UNIX
Lines: 25
Keywords: PATH, shell scripts, absolute names
Summary: set PATH in shell scripts, don't use absolute names

In article <1747@dciem.UUCP>, Dave Legg writes about Ian Darwin's
suggestion that absolute path names not be burned in to shell scripts,
and suggests that they be burned in at the top, in definitions like
TEST=/bin/test.  (This is a particularly bad example since, as Ian
pointed out, test is a shell built-in in modern shells, but /bin/test is
not.)

Ian didn't mention our standard practice here: set PATH at the top of
the shell script (e.g. PATH=/bin:/usr/bin; export PATH). This is really
essential since otherwise an oddball PATH may result in a shell file
executing commands with the same name as standard commands but with
completely different effects.  The author of a shell file usually
intends that the standard commands be used.

Yes, it does mean that your private versions of the standard commands
will not be found in shell files which set PATH to the standard
directories, but this is often just as well. Rather than rehash this
whole issue, I refer the interested reader to The UNIX* Programming
Environment by Brian Kernighan and Rob Pike, in which I believe this
topic is fairly thoroughly covered.

___
* According to p. 8 of the November 1985 issue of "$ echo", an
overpriced AT&T Marketing & Legal rag, I must, being a foreigner, utter
the magic mantra "Trademark of AT&T in the USA and other countries."