NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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



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
 


Home | Main Index | Thread Index | Old Index