Re: command -v in postinsts violating policy
> The Single Unix Specification requires the "command" exists:
> http://www.opengroup.org/onlinepubs/007908799/xcu/command.html. SUS is
> the layman's POSIX.
That's SUSv2. SUSv3 is much closer to POSIX on this issue.
POSIX does, in fact, require "command", but not "command -v", which is a
different, and optional, beast.
> ...it has to be a built in in all the shells we ship as /bin/sh candidates
> and it is (verified for bash and ash, anyway).
pdksh also handles command -v, FWIW.
> If anything is to be done about this (and nothing /needs/ to be done
> about it since nothing is actually broken), a /bin/command could be
> added to an essential: yes package, maybe debianutils or shellutils.
> No dependencies need to be changed because nothing's broken without a
> non-builtin command. (Any new shells that get packaged that wish to be
> suitable to be used as /bin/sh would need to have a versioned dependency,
> though)
I'm not sure what you mean. A user may symlink /bin/sh to a
POSIX-compatible shell, and install any one of those packages only to be
faced with breakage. That's actually broken. Note that this shell
may have an implementation of "command" that does not support -v or -V,
thus not specifying an absolute path will result in failure even if a
/bin/command exists.
It looks as though the most common culprit in these postinsts is
something like
if [ "$1" = configure ] && command -v install-docs >/dev/null 2>&1; then
..
If Policy isn't going to be amended, it would seem reasonable to change
'command -v' to 'type' in this instance.
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: