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

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 21, 2020, 18:57 UTC
Message-ID: <xmqqblopa63n.fsf@gitster.c.googlers.com>
In-Reply-To: <20200321062611.GA1441446@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 13 quoted lines

> 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 ;-)

Show 17 quoted lines

> 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.