Multiple executables in path

[Dan Bernstein]

In article <5657 at idunno.Princeton.EDU> pfalstad at phoenix.Princeton.EDU (Paul Falstad) writes:
> brnstnd at kramden.acf.nyu.edu (Dan Bernstein) wrote:
> >Same as the first one, but converting . in PATH into the actual cwd:
> >  setenv WD "`pwd`"
> >  echo `echo "$PATH" | tr : '\012' | sed -e 's:^\.$:'"$WD": -e 's:$:/!:1': -e 's:^:/.[.]:'`\
> >    | sed 's:/\.\./:/:g'
> This is not really a change in optional behavior, it is a bug fix.  Your
> which should act the right way if you have . in your path.

There was no bug to fix. It is a change in optional behavior. I happen
to think that it's stupid for the output of which to be relative to your
current directory; by that criterion, any version of which that pays
attention to . is wrong. But different people want different behaviors.

> This is kind of confusing.  In order to print only executables, you have
> changed the echo to an ls -dFL and added another expression to the
> second sed.

No. The changes were explained in the order that I did them, one at a
time.

Say you know that foo exists. echo foo just prints foo. ls -dF foo adds
a file type mark. (I said the same thing in the first article.) Do you
understand the first change now?

Now say you have a file list from ls -dF. To extract only the
executables, you check for * at the end of the line. The regexp for this
is \*$. Do you understand the second change now?

> However, with Tom's, the difference is:
> < printf "$path\n" if -x ($path="$dir/$file");
> > printf "$dir/$file\n";

Yeah, so? That's more characters changed than in my version.
Intuitively, though, using $path is analogous to the middle stage with
ls instead of echo, and the -x test is analogous to the * extraction.

(Btw, are you so sure that your change is correct?)

> >The same thing, but showing only the first executable:
> >  ls -dFL `echo "$PATH" | tr : '\012' | sed -e 's:$:/!:1': -e 's:^:/.[.]:'`\
> >    | sed -n -e 's:/\.\./:/:g' -e 's/*$//p' | head -1
> This is a bit inefficient; all you've done here is add one more process
> to filter the output of the original.

You can add it to the sed if you want; I didn't bother.

> I doubt anyone would choose this
> method as a standard implementation for which.

No shit. Standard implementations of commonly used programs are written
in C, because the world doesn't want its computers to be twice as slow.

  [ my commands are shell hacks because they depend on a csh bug ]
  [ that bug is the fact that the result of `` is globbed ]

That isn't a bug; it's a documented feature. You can easily avoid it if
you want.

Paul, something isn't a hack just because it depends on a documented
feature that you don't appreciate.

> You mean, change your implementation so it uses
> aliases from .cshrc?

No, that's not what I said.

> >> (That's only a suggestion.  He probably does like which to have that behavior.)
> >Obviously.
> Wasn't obvious from your article.

Yes, it was; I said so, in plain English.

> You
> sounded like a lazy programmer trying to get out of making a bug fix.

FLAME ON

You and Tom are coming across as so lazy that you'd rather waste
thousands of dollars of money around the world arguing with facts than
spending the two minutes it would take you to figure things out on your
own. Any competent shell programmer can use filters, and I'm not going
to teach you tricks that you can easily figure out for yourself.

FLAME OFF

> >> But Tom's solution can easily be changed to have either behavior.
> >So what? So can any reasonable solution.
> You're not really changing the solution, you're just filtering the
> output.

Paul, given that my solution is composed of filters, doesn't it strike
you as sensible that changing the solution means changing the filters?

> SunOS /usr/ucb/which is a csh script.

Yeah, and slow as per---I mean molasses.

> But you must admit, it's
> hardly an example of good code.

Why? You haven't given any reason for me to admit such a thing.

> I can't see how any csh hack that can't
> easily be translated into a decent shell like sh or ksh can be called
> good code.

``I can't see how any perl hack that can't easily be translated into a
decent language like C can be called good code.'' Who tf cares?

---Dan