[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: egrep moved to /usr/sbin

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 
[jhriv@chao:/tmp/ls]$ cat ls.sh 
[jhriv@chao:/tmp/ls]$ alias ls
bash: alias: `ls' not found
[jhriv@chao:/tmp/ls]$ ls
[jhriv@chao:/tmp/ls]$ alias ls='echo moo!'
[jhriv@chao:/tmp/ls]$ ls
[jhriv@chao:/tmp/ls]$ ./ls.sh 
[jhriv@chao:/tmp/ls]$ function ls.f() { ls; }
[jhriv@chao:/tmp/ls]$ ls.f

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.


Reply to: