Re: egrep moved to /usr/sbin

["John H. Robinson, IV" <jhriv@ucsd.edu>]

Eric Schwartz wrote:
> 
> Not so; it prevents a potential security problem from users who have
> insecure PATH settings.

it prevents sysadmin overriding of binaries by placing site-replacements
in /usr/local/{,s}bin

> By hardcoding the locations of binaries, you prevent them from
> screwing themselves up that way.

by hardcoding the locations, you prevent them from doing neat and
surprising things.

> Also, you can prevent aliases from screwing up your program's output:
> I've found numerous bugs in shell scripts that were caused by my
> aliasing ls to 'ls -FCs', and fixed by forcing ls to /bin/ls.

you must not have been running shell scripts:

[jhriv@chao:/tmp/ls]$ echo $BASH_VERSION 
2.03.0(1)-release
[jhriv@chao:/tmp/ls]$ cat ls.sh 
#!/bin/bash
ls
[jhriv@chao:/tmp/ls]$ alias ls
bash: alias: `ls' not found
[jhriv@chao:/tmp/ls]$ ls
ls.sh
[jhriv@chao:/tmp/ls]$ alias ls='echo moo!'
[jhriv@chao:/tmp/ls]$ ls
moo!
[jhriv@chao:/tmp/ls]$ ./ls.sh 
ls.sh
[jhriv@chao:/tmp/ls]$ function ls.f() { ls; }
[jhriv@chao:/tmp/ls]$ ls.f
moo!

the #!/bin/bash line fires off a nice new bash interpreter, that fails
to inherit the aliases. a shell function runs from within the context of
the current shell, and is affected by shell aliases.

-john