Re: Is "command" working right, yet?

[Bart Schaefer <schaefer@brasslantern.com>]

On Sep 26, 12:31am, Martijn Dekker wrote:
}
} The culprit seems to be the simplistic option parsing code starting at
} line 2664 in Src/exec.c (current git, e35dcae):
} 
} Sure enough, it looks if there's one option and if there is, it happily
} ignores the rest. Combined options like -pV also aren't supported.

Not exactly.  That whole thing is in a "while" loop, so as long as -p
and -v and/or -V are in separate words I think the expectation was
that it would loop around and discover the next one .. but if -p is
first, it doesn't loop, and if -v or -V is first then -p is rejected
because it's not [and can't be, see below] listed in the value of
"commandbn" [exec.c 209].

} I don't understand nearly enough about the zsh codebase to know why this
} routine does its own option parsing rather than calling some common
} option parsing function, so I can't offer suggestions for improvement

It's because "command" is a sort-of keyword instead of a builtin, so it
doesn't go through the regular builtin dispatch where the common option
parsing lives.  Originally zsh's "command" prefix didn't accept any
options, so this parsing was bolted on bit by bit as POSIX defined them.

A complication is that "command -v" is defined in terms of bin_whence(),
and "whence" has a -p option that means something different.