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.