ron@uthub.UUCP (Ron Wessels) (12/09/85)
>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
henry@utzoo.UUCP (Henry Spencer) (12/13/85)
> 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. No, the one the shell-file writer can trust is PATH=/bin:/usr/bin rm, not /bin/rm. /bin/rm may not even exist (although it would be surprising).