Thread (1 message) 1 message, 1 author, 2020-03-21

Re: [PATCH] test-lib: allow short options to be stacked

From: Junio C Hamano <hidden>
Date: 2020-03-21 18:57:40

Jeff King [off-list ref] writes:
I wondered if we could do this without the extra process. This works:

  opt=${opt#-}
  while test -n "$opt"
  do
	extra=${opt#?}
	this=${opt%$extra}
	opt=$extra
	parse_option "-$this"
  done

It's a little convoluted. I'm not sure if saving a process per unbundled
short option is worth it.
I was wondering if I should suggest something similar to the above
when I wrote my response.  Yours actually does not look as bad as
what mine would have been ;-)
What happens to bundled short options with arguments? I think "-r" is
the only one. We don't allow "stuck" short options like "-r5", so we
don't have to worry about feeding non-option bits to parse_option(). It
looks like we'd only examine $store_arg_to outside of the short-option
loop, so we'd treat:

  ./t1234-foo.sh -vrix 5

the same as:

  ./t1234-foo.sh -v -r 5 -i -x

which seems reasonable. But:

  ./t1234-foo.sh -rr 5 6

would get garbled.
And also we declare we will never add any option that takes an
argument with this patch?  ... Ah, no, it is just store_arg_to is
taking a short-cut assuming the current lack of bundled options.

OK, so yeah, I am not sure if this half-way "solution" is worth it.
It is just the test scripts, sure, that we have this strange
limitation that "-rr 5 6" is not parsed correctly (i.e. "do not use
the bundled form if -r is involved" is something developers can live
with), but then it is just the test scripts so "do not use the
bundled form at al" is not too bad, either.  It is just one less
thing for developers to remember, compared to having to remember
"you can, but except for this special case".

So, I dunno.

Thanks.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help