Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site dciem.UUCP
Path: utzoo!dciem!davel
From: davel@dciem.UUCP (Dave Legg)
Newsgroups: net.unix-wizards
Subject: Re: Please do NOT use "/bin/test" as a command name
Message-ID: <1747@dciem.UUCP>
Date: Mon, 9-Dec-85 09:25:57 EST
Article-I.D.: dciem.1747
Posted: Mon Dec  9 09:25:57 1985
Date-Received: Mon, 9-Dec-85 11:07:24 EST
References: <313@bdaemon.UUCP> <13400016@mirror.UUCP> <1016@sdcsla.UUCP> <1019@utcs.uucp>
Reply-To: davel@dciem.UUCP (Dave Legg)
Organization: D.C.I.E.M., Toronto, Canada
Lines: 49
Summary: 

> = Ian Darwin
>> = Larry West

In article <1019@utcs.uucp> ian@utcs.UUCP (Ian F. Darwin) writes:
>In article <1016@sdcsla.UUCP> west@sdcsla.UUCP (Larry West) writes:
>>However, I would like to point out that users have a habit
>>of naming programs "test", and of having "/bin" occur late
>>in their paths.   ...
>>
>>So, my suggestion is to always use "/bin/test" instead
>>of simply "test", or else use "[ ]".   ...
>
>No, no, no. Do not use absolute paths for test, mv, cp, or
>anything else. Least of all in shell files.
>

I can see both sides of this, I have run  up against a user reporting a
strange failure of a shell script that is installed for general use, and
which usually works with no problem.   The problem is that the user that
finds such a problem is usually new and inexperienced, and it can take
signifigant amounts of time to find that the whole problem is simply a
name collision.  

One point not mentioned in the article I saw was that of the collision
with a users program that had undesirable side effects.  For example,
if a user writes a program to delete files, and calls it some common system
program name, then runs a script (which he might not even know is a script)
which calls on that name.

I have a  suggestion.
Set a shell variable to the absolute path of the program, i.e.
TEST=/bin/test (or equivelent for other shells)
and use $TEST in the shell program.  This isolates the dependencies at
the top of the script, making for easy changes.  As for portability,
if the changes are obvious and at the top, then any body getting a script
from the net should be able to see what is necessary.  
Anybody recieving a script will normally at least scan it briefly to see
what it does, especially if it fails.  

Although I can see that it is generally
desirable to be as portable as possible,  in shell scripts, I now normally
fully qualify all proram names via  the above convention.  This is purely
on the basis of experience with problems caused by unqualified program
names in scripts. 

-- 
Dave Legg, DCIEM, Toronto, Ont. Canada.    (416) 635-2065
{linus,ihnp4,uw-beaver,floyd}!utcsri!dciem!davel
{allegra,ihnp4,linus,decvax}!utzoo!dciem!davel