Re: bin/54803: /bin/sh: apparent regression with "type -p" (alias tracking?)

["David H. Gutteridge" <david%gutteridge.ca@localhost>]

The following reply was made to PR bin/54803; it has been noted by GNATS.

From: "David H. Gutteridge" <david%gutteridge.ca@localhost>
To: gnats-bugs%netbsd.org@localhost, kre%netbsd.org@localhost
Cc: 
Subject: Re: bin/54803: /bin/sh: apparent regression with "type -p" (alias
 tracking?)
Date: Sat, 28 Dec 2019 16:32:25 -0500

 On Sat, 2019-12-28 at 13:30 +0000, Robert Elz wrote:
 >      Date:        Sat, 28 Dec 2019 01:30:02 +0000 (UTC)
 >      From:        "David H. Gutteridge" <david%gutteridge.ca@localhost>
 >      Message-ID:  <20191228013002.79F5D7A1D8%mollari.NetBSD.org@localhost>
 >  
 >    |  It looks to me that this was a regression introduced in v. 1.53
 > of
 >    |  exec.c. But I may well be missing something.
 >  
 >  Well, yes, as in the cvs log says (which I failed to remember
 > earlier):
 >  
 >    3. Stop the "type" builtin inheriting the args (-pvV) that
 > "command" has
 >       (which it did, as when -v -or -V is used with command, it and
 > type are
 >       implemented using the same code).
 
 Yes, I misconstrued what you'd meant by "inherited", and should have
 re-read that after looking at the code, sorry. It's quite clear now.
 
 >  The history here is that "command -v" (and "command -V") are
 > implemented
 >  by the same code as implements "type".   Exactly the same
 > code.  "command"
 >  has -v -V and -p as options, therefore our implementation of "type"
 > did
 >  as well.   However type was never documented to take any options, nor
 > is
 >  the posix "type" command specified as taking any options (they're not
 >  disallowed, just there are none).
 >  
 >  I tested a bunch of other shells ... the ksh variants, bash, and
 > somewhat
 >  surprisingly yash, all allow the -p option (bash alone also permits
 > -P), the
 >  FreeBSD shell treats options as just more command names (I'm not sure
 > that's
 >  strictly correct), dash and bosh act as we do now, and give a usage
 > message.
 >  
 >  The ksh variants allow -p, as for them "type" is just an alias of
 > "whence"
 >  which does have options (including -p) and yash makes "type" the
 > equivalent of
 >  "command -V" (and so permits the options that "command" takes (which
 > includes 
 >  -p).
 >  
 >  Note that for bash, the -P option to type is more or less what the
 > others
 >  give you with -p (path search, though exactly what that implies is
 > not
 >  consistent), the "-p" option to bash makes the output less verbose
 > (more
 >  suitable for use in a script, just as the -p option behaves in things
 > like
 >  "export").
 >  
 >  I am not sure what is best here, I would certainly not recommend
 > using "type"
 >  for anything that matters - its output format isn't (anywhere)
 > defined, its
 >  exit status is defined but just as "0: no errors, >0: an error
 > occurred"
 >  but there's no specification of what kind of error that might be -
 > certainly
 >  it is not specified that "not found" is an error for which a status
 > != 0
 >  will be returned.
 >  
 >  I'd use "command" (probably "command -v" rather than -V though one of
 > those
 >  options is necessary) rather than "type" for the purpose described,
 > that
 >  one at least specifies that the exit status (of command -v or -V) is
 > != 0
 >  when the command named is not found, and it is specified what -p
 > means.
 >  
 >  About the only thing missing from "command -[Vv]" is that command
 > permits
 >  just one command name, whereas "type" allows many.  As described I
 > don't
 >  think that is likely to matter.
 
 The configure script in question was generated from an old version of
 GNU autoconf (2.63), and has these comments:
 
     ## which doesn't work in ash, if /usr/bin/which isn't installed
     ## type -p doesn't work in ash
     ## command -v doesn't work in zsh
     ## command -v "$r" 2>&1
     ## this test should work in ash, bash, pdksh (ksh), zsh
     type -p $r 2>/dev/null | tail -n 1 | awk '{print $NF}'
     
 The contradictions of the second and fifth comments aside, the concern
 about "command -v" in zsh is dated, since modern zsh does support that.
 (I also see zsh explicitly accepts "type -p", since it's an alias of
 "whence".) Trying to be as broadly compatible as possible seems quite
 difficult!
 
 >  So, I am not sure what we should do here (if anything) - while the -p
 > (and
 >  -v and -V) options to type did go away, they were never docmuented as
 >  existing, that they did was just an implementation artifact - a bug
 > if you
 >  like - to be fixed (as both the FreeBSD shell and dash have
 > apparently done,
 >  though in different ways), which is what happened.
 >  
 >  Reverting to the previous behaviour is trivial - it just means
 > deleting (or
 >  altering) the check for options intended for "command" being given
 > when the
 >  command being executed is "type".
 >  
 >  It might not work quite the same way as it did, as there were other
 > bug
 >  fixes to the "command" command, which will have (cannot avoid having
 > with
 >  the current implementation) a flow through to type but given how
 > imprecisely
 >  "type" is specified (and how different the implementations) it would
 >  probably work well enough for the purpose if it failed to give a
 > usage
 >  message for "-p".
 >  
 >  I am open to receiving opinions, but my default state unless there is
 >  considerable demand, is to keep things as they are now (that is,
 > "type"
 >  allows no options).   That is do do what our manpage says:
 
 Given I'm the only person who's raised this, due to one upstream
 project's scripting, and also given there are other Bourne-compatible
 shells that also reject or parse "type -p" differently, I don't think
 we need to change anything, then.
 
 Thanks for your detailed response, it was very helpful! I'm going to
 take your advice for the fix to the Lilypond package.
 
 Dave