Re: [PATCH] rev-parse --parseopt: fix handling of optional arguments
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Oct 15, 2013, 23:33 UTC
- Message-ID
- <xmqqfvs29kjc.fsf@gitster.dls.corp.google.com>
- In-Reply-To
- <20131015231427.GF9464@google.com>
Jonathan Nieder <jrnieder@gmail.com> writes:
Show 40 quoted lines
> Nicolas Vigier wrote: > >> $ cat /tmp/opt.sh >> #!/bin/sh >> OPTIONS_SPEC="\ >> git [options] >> -- >> q,quiet be quiet >> S,gpg-sign? GPG-sign commit" >> echo "$OPTIONS_SPEC" | git rev-parse --parseopt $parseopt_extra -- "$@" >> >> Then the following two commands give us the same result : >> >> $ /tmp/opt.sh -S -q >> set -- -S -q -- >> $ /tmp/opt.sh -S-q >> set -- -S '-q' -- >> >> We cannot know if '-q' is an argument to '-S' or a new option. > > Hmph. > > As Junio mentioned, inserting '' would be a backward-incompatible > change. I don't think it's worth breaking existing scripts. Probably > what is needed is a new parseopt special character with the new > semantics (e.g., > > Use ?? to mean the option has an optional argument. If the > option is supplied without its argument, the argument is taken > to be ''. > > or something like > > Use ?<default> to mean the option has an optional argument. If > the option is supplied without its argument and <default> is > nonempty, the argument is taken to be <default>. > > ). > > Sensible?
You just made these two that the user clearly meant to express two different things indistinguishable.
opt.sh -S
opt.sh -S ''So I do not think it is sensible. In fact, I do not think there is any sensible way to handle a shortopt with optional parameter that is not at the end of the command line.
And that is exactly why gitcli.txt tells users to use the 'sticked' form, and ends the bullet point with:
An option that takes optional option-argument must be written in the 'sticked' form.
That still does not give the command line a way to express an option that could take an optional argument without the optional argument in the middle of the command line, though.