Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site uthub.UUCP
Path: utzoo!utcsri!utai!uthub!ron
From: ron@uthub.UUCP (Ron Wessels)
Newsgroups: net.unix-wizards
Subject: Please DO use "/bin/test" as a command name
Message-ID: <247@uthub.UUCP>
Date: Mon, 9-Dec-85 02:51:45 EST
Article-I.D.: uthub.247
Posted: Mon Dec  9 02:51:45 1985
Date-Received: Tue, 10-Dec-85 17:47:49 EST
References: <313@bdaemon.UUCP> <13400016@mirror.UUCP> <1016@sdcsla.UUCP> <1019@utcs.uucp>
Organization: CSRI, University of Toronto
Lines: 28

>From: ian@utcs.uucp
>Subject: Please do NOT use "/bin/test" as a command name
>Message-ID: <1019@utcs.uucp>
>
> No, no, no. Do not use absolute paths for test, mv, cp, or
> anything else. Least of all in shell files.  ...
> 					    ....it violates the 
> portability principle: UNIX uses the PATH environment variable
> to find programs, rather than making the user specify full path names
> for programs. This allows you to write your own. ...
> ...
> You don't know what might motivate me to have my own version of rm
> ...

There's one small problem with that, Ian.  People writing "portable"
shell files don't know the behaviour of *your* rm (for example).  What
flags does it take?  Does it support the same ones as /bin/rm?  Does it
behave similarly? I know some people that move rm'ed files to their own
private pergatory, in case they ever want them back.  Others have their
own "rm" that does a "/bin/rm -i".  A lot of otherwise-correct shell
files will behave very strangely if they use this non-standard version.
In short, /bin/rm is the only one that the shell-file writer can trust
to execute as s/he expects, and so should be the one invoked.
-- 
Ron Wessels	Computer Systems Research Institute	University of Toronto
UUCP:	{decvax,floyd,ihnp4,linus,utzoo,uw-beaver}!utcsri!ron
CSNET:	ron@Toronto
ARPA:	ron%Toronto@CSNet-Relay