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

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> 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.