From: Junio C Hamano Date: Tue, 15 Oct 2013 23:33:27 GMT Subject: Re: [PATCH] rev-parse --parseopt: fix handling of optional arguments Message-ID: In-Reply-To: <20131015231427.GF9464@google.com> Jonathan Nieder writes: > 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 ? to mean the option has an optional argument. If > the option is supplied without its argument and is > nonempty, the argument is taken to be . > > ). > > 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.