On Thu, Apr 01, 2004 at 02:26:56PM -0800, Simon J. Gerraty wrote:
> >That and built-ins are the two reasons I think we shouldn't try to use an=
> >=20
> >external command.
> 
> Yes and no.  Many scripts want to simply - and exactly, locate a binary
> via $PATH or know that no such binary exists.
> 
> The existing which(1) is inappropriate due since its a csh script
> and follows the wrong semantics for the above.

Yes, but it follows the _appropriate_ semantics for which(1), which is,
very explicitly, supposed to find the binary *where csh, invokved
without -f, would find it, for the user in question*.  What OpenBSD
and FreeBSD do is wrong; you can't do the right thing without
invoking csh, since to DTRT means you have to be able to parse arbitrary
csh scripts.  My .cshrc, for example, evaluates several conditionals
before setting $PATH.  Our which(1), as well as our csh builtin, do the
right thing; OpenBSD's gets it completely wrong, as you'd expect.

If you don't agree with me about what which(1) is supposed to do, I guess
you could ask Bill Joy -- but I don't think you're really going to get a
different answer...

A pattern of misunderstanding and misuse of the command doesn't mean that
what it *is* supposed to do magically changes.

> Shell builtins like type, whence etc, are also not very useful since every 
> shell has a different one, and not all of them do just the above.

That's not so.  POSIX-conformant Bourne shells have the same one, which
does what you want; we ship two shells that are intended to be POSIX-
conformant (ksh and sh) and one that's not (csh), and the latter has a
scripting syntax so different from that of Bourne shell that there's
basically no chance of running a nontrivial Bourne shell script through
it anyway, so the fact that you have to use "which" instead of "type"
is basically irrelevant.

Thor