Zsh Mailing List Archive
Messages sorted by:
Re: Is "command" working right, yet?
- X-seq: zsh-workers 39440
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxx
- Subject: Re: Is "command" working right, yet?
- Date: Sun, 25 Sep 2016 20:13:28 -0700
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:date:in-reply-to:comments:references:to:subject :mime-version; bh=rctyjtNNe6r4rB57ExRmUYrh5nPxObvOcPV96YpJPAo=; b=oVYL4gNAAVdaKaHMV/ttQJ7pv7CGcNj1fKGTZEulTGdqJg96SdF36aBAo2rHg6o5YP SfwDMSasKIY2VA1c/8Kts35H0xoPPtc23V1bDmsLIIPMs/OaIoDGXj3e8lPj1x4UihzQ r8HgayNHpAI5IRIeMQS+NjM1fZxJzpO6VWq0n6zlZpHC/ZPKt5VuouNV3kdHd6Ho4bCF LDzr1p51BFtUVzDrfjI1YZSkdNnflbuvBVQijqCU9MbHKyAxnRHsqwyURhTMmuLwPOHV Xgj7VyRTDVh0M8zhZ+0S6jQunt6iVD9omp7GqMF+qA/FKsoMO4jtdk6LBDu7uTyC0T7Y fG5A==
- In-reply-to: <email@example.com>
- List-help: <mailto:firstname.lastname@example.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:email@example.com>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <160202163744.ZM2066@torch.brasslantern.com> <56B761B8.firstname.lastname@example.org> <email@example.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.
Messages sorted by: