On Wed, Nov 23, 2022 at 11:31:57PM +1059, Reuben mac Saoidhea wrote:
> i hate to harp on about it, but:
>
> in case you happen to discover the `command' command,
> beware that its description in sh(1) is wrong.
>
> sh(1) says:
> command -vV command args ...
>
actually openbsd's sh(1) pages says:
command [-p | -V | -v] command [arg ...]
> in fact it is:
> command -vV command ...
>
yes, -v and -V are different. instead of invoking command, they identify
information about "command", such as path used to run it.
so we could do like posix and show two differing forms:
command [-p] command_name [argument]
command [-p][-v|-V] command_name
however one of the goals of sh(1) was brevity. to that end it is
combined, and i think it is obvious that if you are asking "command" to
identify whether something is a function (or whatever) then it would be
silly to specify it with arguments.
> note in particular, that, like `type',
> command -V command echo
>
> outputs
> command is a shell builtin
> echo is a shell builtin
well, posix makes no claim that multiple arguments are supported with
either -v or -V. openbsd's sh(1) page does not say this either. you
could write some code to improve how this is handled, i suppose.
having said that, ksh(1) seems to contradict what i've just said:
If the -v option is given, instead of executing cmd, information
about what would be executed is given (and the same is done for
arg ...).
that doesn;t seem to be the case. i'm not sure whether ksh(1) is wrong
or it's expected to behave differently.
>
> rather than what `command -V' ought to output:
> command echo is /bin/echo
>
$ command -V echo
echo is a shell builtin
jmc
> to find out what `command blahcommand' means to sh(1), use
> whereis blahcommand
>
> to find out what `blahcommand' means to sh(1), use
> type blahcommand
>
> noting that `type' is explained in `man sh',
> and that `tracked alias' means `hash'.
> (note that using `type' affects `hash'.)
>
> isnt *N*X FUN!?
>
