Bug#747320: Mandate "type" in /bin/sh
On Wed, May 07, 2014 at 02:32:39PM +0100, Ian Jackson wrote:
> I therefore propose that the following should be added to the list of
> additional features listed in policy 10.4:
>
> * The XSI extension `type' must be supported . It must exit
> zero iff the command is found. The output format is not
> specified and scripts must not rely on it; scripts should
> rely only on the exit code using a construct such as
> if type foo >/dev/null 2>&1; then ...
As the author of the original shell incarnation of what's now
/usr/bin/which, and having worked around the lack of a policy-authorised
in-process idiom for this in a number of places, I would also like to
see such an extension in policy. It's been a long-standing irritation
to have to duplicate this code everywhere for the sake of strict
conformance.
We should, though, survey the set of shells in Debian (excluding posh,
which should follow policy in this regard) to find out if any of them
lack "type" and if not make sure that they're extended appropriately.
mksh seems to have it. I haven't checked any others.
We need to say something about options. POSIX simply says "none". dash
treats all of its arguments as names regardless of whether they begin
with an option. bash has a number of options and the GNU-style "--"
end-of-options indicator. Policy therefore probably ought to say that
the behaviour of "type" with any arguments beginning with "-" is not
specified (so you can't use bashisms like "type -P" to force a PATH
search).
--
Colin Watson [cjwatson@debian.org]
Reply to: