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

[Robert Elz <kre%munnari.OZ.AU@localhost>]

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

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: bin/54803: /bin/sh: apparent regression with "type -p" (alias tracking?)
Date: Sat, 28 Dec 2019 20:29:00 +0700

     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).
 
 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.
 
 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:
 
    type [name ...]
             Interpret each name as a command and print the resolution of the
             command search.  Possible resolutions are: shell keyword, alias,
             shell built-in, command, tracked alias and not found.  For aliases
             the alias expansion is printed; for commands and tracked aliases
             the complete pathname of the command is printed.
 
 kre
 
 ps: at some stage the "tracked alias" output variant which is some ksh
 invented terminology, that almost no-one really comprehends (it just means
 a filesystem command that was located in the hash table, rather than by
 actually doing a path search) is likely to go away, as it leads to lunacy like:
 
 	[jinx]{2}$ type whois
 	whois is /usr/bin/whois
 	[jinx]{2}$ type whois
 	whois is a tracked alias for /usr/bin/whois
 
 as the first "type whois" conveniently adds the "whois" command to the
 hash table as a side effect of the path search which located it, so the
 first time "whois" was not in the hash table, and so is reported as just
 the command, whereas the next time it is there already, and is reported
 as a "tracked alias" instead.   Note that you have to be looking for a
 command that is not in the hash table initially to see this effect, which
 is why I chose "whois" as the target.