git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] rev-parse --parseopt: fix handling of optional arguments

From
Nicolas Vigier <boklm@mars-attacks.org>
Date
Oct 16, 2013, 14:14 UTC
Message-ID
<20131016141411.GB4589@mars-attacks.org>
In-Reply-To
<20131015235739.GI9464@google.com>
On Tue, 15 Oct 2013, Jonathan Nieder wrote:
Show 60 quoted lines
> Junio C Hamano wrote:
> 
> > You just made these two that the user clearly meant to express two
> > different things indistinguishable.
> >
> > 	opt.sh -S
> >       opt.sh -S ''
> [...]
> > 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.
> 
> Yes, another possibility in that vein would be to teach rev-parse
> --parseopt an OPTIONS_LONG_STICKED output format, and then parse with
> 
> 	while :
> 	do
> 		case $1 in
> 		--gpg-sign)
> 			... no keyid ...
> 			;;
> 		--gpg-sign=*)
> 			keyid=${1#--gpg-sign=}
> 			...
> 			;;
> 		esac
> 		shift
> 	done
> 
> This still leaves
> 
> 	opt.sh -S
> 	
> and
> 
> 	opt.sh -S''
> 
> indistinguishable.  Given what the shell passes to execve, I think
> that's ok.
> 
> The analagous method without preferring long options could work almost
> as well:
> 
> 	while :
> 	do
> 		case $1 in
> 		-S)
> 			... no keyid ...
> 			;;
> 		-S?*)
> 			keyid=${1#-S}
> 			...
> 			;;
> 		esac
> 		shift
> 	done
> 
> but it mishandles "--gpg-sign=" with empty argument.
I'm thinking about a patch to add the following two options to rev-parse :
--sticked-opt-args::
	Only meaningful in --parseopt mode. Tells the options parser to
	output options with optional arguments in sticked form. The
	default is to output them in non-sticked mode, which can be
	difficult to parse unambiguously.
--long-options::
	Only meaningful in --parseopt mode. Tells the options parser to
	output long option names, when available. The default is to use
	short option names when available.

When you want to handle optional args unambiguously, you use the --sticked-opt-args option. And if you think an empty value can be a meaningful value, you add the --long-options option to be able to distinguish them.

Would it make sense ?
Previous: Nicolas VigierNext: Jonathan Nieder
Message 12 of 25 in “rev-parse --parseopt: fix handling of optional arguments”
  1. rev-parse --parseopt: fix handling of optional argumentsNicolas Vigier, Oct 15, 2013
  2. Junio C HamanoOct 15, 2013
  3. Nicolas VigierOct 15, 2013
  4. Jonathan NiederOct 15, 2013
  5. Junio C HamanoOct 15, 2013
  6. Jonathan NiederOct 15, 2013
  7. Johannes SixtOct 16, 2013
  8. Jeff KingOct 16, 2013
  9. Junio C HamanoOct 16, 2013
  10. Jeff KingOct 16, 2013
  11. Nicolas VigierOct 16, 2013
  12. Nicolas VigierOct 16, 2013
  13. Jonathan NiederOct 16, 2013
  14. rev-parse --parseopt: add the --sticked-long modeNicolas Vigier, Oct 25, 2013
  15. Junio C HamanoOct 25, 2013
  16. Nicolas VigierOct 25, 2013
  17. Junio C HamanoOct 25, 2013
  18. Philip OakleyOct 26, 2013
  19. Junio C HamanoOct 28, 2013
  20. sticked -> stuckNicolas Vigier, Oct 31, 2013
  21. 1/2 Use the word 'stuck' instead of 'sticked'Nicolas Vigier, Oct 31, 2013
  22. Junio C HamanoOct 31, 2013
  23. 2/2 rev-parse --parseopt: add the --stuck-long modeNicolas Vigier, Oct 31, 2013
  24. Michael HaggertyOct 27, 2013
  25. Nicolas VigierOct 15, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.