From: Bart Schaefer <schaefer@brasslantern.com>
To: toki clover <tokiclover@gmail.com>, zsh-users@zsh.org
Subject: Re: zsh[modules]/zutil: zparseopts should parse alternate long options
Date: Mon, 09 Apr 2012 14:42:25 -0700 [thread overview]
Message-ID: <120409144225.ZM28987@torch.brasslantern.com> (raw)
In-Reply-To: <CAGw_SrOBWv=s2Re8oZga=DSfqjQfEAJHXy9xfTqFzKNJuh4Z5Q@mail.gmail.com>
On Apr 9, 2:12pm, toki clover wrote:
}
} Now, it would be nice if an alternate long option e.g. `-option'
} instead of the GNU style `--option' would work, because in the present
} day, if the first letter of a long option name is a short option name,
} the long option would never be parsed as one would expect.
An example would help to clarify your question. Do any of the following
explain what you mean? If not, could you provide a sample?
Given
ARGV=(-option)
zparseopts o=shortopts option=longopts
the entire string "-option" will be placed in the array "$longopts",
which seems to be what you want. Given
ARGV=(-option -o)
zparseopts o=shortopts option=longopts
then $shortops will contain "-o" and $longopts will contain "-option".
In fact zparseopts normally attempts to make the longest match first, so
except in ambiguous cases option=longopts will always consume -option
before o=shortopts is attempted. Only when no spec is matched that can
be treated as a single element does zparseopts fall back to handling
the prefix of -option as if it were -o.
The ambigous case happens with
zparseopts option=longopts o:=shortopts
where -option could be parsed as either [-o with argument ption] or as
[-option]. The above would place (-o ption) in $shortopts and leave
nothing for $longopts. However, this can be handled by making two
passes with separate specs:
zparseopts -E -D option=longopts
zparseopts -D o:=shortopts
In fact as currently implemented zparseopts scans the specs in reverse
order from last to first, so the above two passes are the same as
zparseopts -D o:=shortopts option=longopts
but that's undocumented so not guaranteed to remain the case. Since
using -E is an imperfect solution for the two-pass example, it would
probably not be unreasonable to suggest that the search order should
become documented and therefore trustworthy.
prev parent reply other threads:[~2012-04-09 21:42 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-09 14:12 toki clover
2012-04-09 21:42 ` Bart Schaefer [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=120409144225.ZM28987@torch.brasslantern.com \
--to=schaefer@brasslantern.com \
--cc=tokiclover@gmail.com \
--cc=zsh-users@zsh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).