Multiple executables in path (Was: NON-SOURCE POSTINGS CONSIDERED HARMFUL!)

[Paul Falstad]

maart at cs.vu.nl (Maarten Litmaath) wrote:
>In article <9688:Jan2313:09:4391 at kramden.acf.nyu.edu>,
>	brnstnd at kramden.acf.nyu.edu (Dan Bernstein) writes:
>)> 	% which passwd
>)> 	/bin/passwd /usr/bin/passwd /etc/passwd
>)> 	# How odd: /etc/passwd is executable!
>)I like a which that points out non-executables in PATH, because it shows
>)quite clearly any wasted exec()s.
>I like a `which' that gives the right answer all the time, that is, the
>answer to the following question:
>	When I type a command, say `foo', which file will be executed?

Good point.  But if you do agree with Dan, and want a which that points
out non-executables in PATH, you can make a simple easy obvious change
to Tom's perl script (take out the -x, move the $path assigment) to make it
do that.  His is much more flexible.  If you don't agree with Dan, and want
to fix the csh version to exclude non-executables, after deciphering the csh
brain-damage you'd discover that there's no way to change it.  Perhaps
since Dan can't fix his which, he's decided that it's OK the way it is.
(That's only a suggestion.  He probably does like which to have that behavior.)
But Tom's solution can easily be changed to have either behavior.

>)> 	% set path=($path .)
>)> 	% cp /bin/true foo
>)> 	% which foo
>)> 	# Silence.
>)It is a mistake to have . (or any other relative directories, if your
>)system supports them) in your path.

That's nice, but the fact is many people do have . in their path (it's
last in the default path at our site).  You're saying, "Well, my version
doesn't work if you have . in your path, so don't put . in your path."
"Doctor, it hurts when I do this."  "So don't do that."

I agree that's its not too smart to have . in your path.  (I don't.)
But for those who do, it's all the more important for which to report
executables in the current directory, to make sure you're not about to
execute a trojan horse by accident.  In any case, your version should do
something sensible when someone has . in his path; instead it does
something strange, and it's hard for someone who doesn't speak csh to
figure out why after looking at your code.

Again I could ask, does your csh alias behave this way because you
designed it to, or because there's no other way it could act?  The perl
solution could easily be changed to print a blank line or print garbage
or coredump if you're stupid enough to have . in your path; your
solution is not so flexible.

>)> Had you read the documentation of `which5', you would have known it's not
>)> that trivial to get things right.
>)
>)Different people will prefer different behaviors of ``which''; [...]
>
>Agreed.  But some types of behavior are questionable at best, ridiculous
>at worst.

Dan prefers the behavior of his which because the crufty language it's
written in allows no other behavior.  How convenient.  Yet different people
can easily change the perl solution to have the different behaviors they
prefer.  That seems much more sensible to me.

Aren't flame wars fun?

--
Paul Falstad, pfalstad at phoenix.princeton.edu PLink:HYPNOS GEnie:P.FALSTAD
In the heat of composition I find that I have inadvertently allowed
myself to assume the form of a large centipede.  I am accordingly
dictating the rest to my secretary.
409 shift/reduce, 62 reduce/reduce conflicts.  Beat that!