Path: utzoo!utgpu!cs.utexas.edu!rutgers!njin!princeton!phoenix.Princeton.EDU!pfalstad From: pfalstad@phoenix.Princeton.EDU (Paul Falstad) Newsgroups: alt.sources.d Subject: Re: Multiple executables in path (Was: NON-SOURCE POSTINGS CONSIDERED HARMFUL!) Message-ID: <5648@idunno.Princeton.EDU> Date: 24 Jan 91 07:36:45 GMT References: <8807@star.cs.vu.nl> <9688:Jan2313:09:4391@kramden.acf.nyu.edu> <8833@star.cs.vu.nl> Sender: news@idunno.Princeton.EDU Organization: The E. Henry Thripshaw Fan Club Lines: 69 maart@cs.vu.nl (Maarten Litmaath) wrote: >In article <9688:Jan2313:09:4391@kramden.acf.nyu.edu>, > brnstnd@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@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!