Re: command -v in postinsts violating policy

[Richard Braakman <dark@xs4all.nl>]

On Sun, May 26, 2002 at 08:27:03PM -0400, Joey Hess wrote:
> Branden Robinson wrote:
> > So far, no one has proposed a standards-compliant way of solving the
> > problem that retains command -v's robustness.
> 
> What specific problems do you have with the idea of using "which"?

I don't like it that "which" spawns a new shell, compared to "command -v"
being builtin.  It's also less well defined -- it happens to return a
useful exit code on Debian, but how portable is that?  (And the only
reason we're worried about command -v in the first place is portability.)
In addition, which is in debianutils.  It's an Essential package, but that
can still cause difficulties if other Essential packages rely on it.
You'd have to be careful with debhelper in that regard.

Oh, well, apparently zsh has problems with command -v.  My opinion is
that zsh can wave POSIX around if it wants to, but POSIX is a too small
standard for real life, and I thought the whole point of making our own
distribution was that we can fix things instead of working around them.

One difference between which and command -v is that which doesn't
return true for aliases.  But is that really what you want?  If someone
defined install-docs as an alias to something else, shouldn't it just
work?  Why go out of your way to fail in that case?
If you just want to know if a program foo can be executed, then the code
for which can be simplified to:
    /bin/bash -c "type -p -- foo"
and this works on all shells.

What, you say it's ugly to invoke bash from a /bin/sh script?  But that's
exactly what invoking "which" does, try cat /usr/bin/which.  Since the
main reason we're worried about compatibility is so that people can run
more efficient shells such as ash as /bin/sh, it sort of defeats the point
if we then go and invoke bash to do something that ash can do.  Maybe we
should just have a Death Match between ash and zsh fanatics, and let
the best shell win :-)

(Sorry for the lack of coherence, it's late here.  For the record, my
recommendation is to add to Policy that /bin/sh must support command -v.
And I'd like it if our policy was defined in terms of a standard we can
actually access.)

Richard Braakman


-- 
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org