threads / patch / 53045

patchtest-lib: allow short options to be stacked

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

## tl;dr

16 messages between Mar 21, 2020 and Mar 23, 2020. Diffs are folded; open one to read it.

replies: 15people: 5as markdown or json

Matheus Tavares· Mar 21, 2020, 03:07 UTC · lore

When debugging a test (or a set of tests), it's common to execute it with some combination of short options, such as:

	$ ./txxx-testname.sh -d -x -i

In cases like this, CLIs usually allow the short options to be stacked in a single argument, for convenience and agility. Let's add this feature to test-lib, allowing the above command to be run as:

	$ ./txxx-testname.sh -dxi
	(or any other permutation, e.g. '-ixd')
Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br>
---
 t/README      |  3 ++-
 t/test-lib.sh | 46 ++++++++++++++++++++++++++++++++--------------
 2 files changed, 34 insertions(+), 15 deletions(-)
Show changes to 2 files +34 −15

t/README, t/test-lib.sh

diff --git a/t/README b/t/README
index 9afd61e3ca..c3cf8f617b 100644
--- a/t/README
+++ b/t/README
@@ -69,7 +69,8 @@ You can also run each test individually from command line, like this:
 
 You can pass --verbose (or -v), --debug (or -d), and --immediate
 (or -i) command line argument to the test, or by setting GIT_TEST_OPTS
-appropriately before running "make".
+appropriately before running "make". Short options can be stacked, i.e.
+'-d -v' is the same as '-dv'.
 
 -v::
 --verbose::
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 0ea1e5a05e..14363010d2 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -72,119 +72,137 @@ then
 	if test -n "$GIT_TEST_INSTALLED"
 	then
 		echo >&2 "error: there is no working Git at '$GIT_TEST_INSTALLED'"
 	else
 		echo >&2 'error: you do not seem to have built git yet.'
 	fi
 	exit 1
 fi
 
-# Parse options while taking care to leave $@ intact, so we will still
-# have all the original command line options when executing the test
-# script again for '--tee' and '--verbose-log' below.
-store_arg_to=
-prev_opt=
-for opt
-do
-	if test -n "$store_arg_to"
-	then
-		eval $store_arg_to=\$opt
-		store_arg_to=
-		prev_opt=
-		continue
-	fi
+parse_option () {
+	local opt="$@"
 
 	case "$opt" in
 	-d|--d|--de|--deb|--debu|--debug)
 		debug=t ;;
 	-i|--i|--im|--imm|--imme|--immed|--immedi|--immedia|--immediat|--immediate)
 		immediate=t ;;
 	-l|--l|--lo|--lon|--long|--long-|--long-t|--long-te|--long-tes|--long-test|--long-tests)
 		GIT_TEST_LONG=t; export GIT_TEST_LONG ;;
 	-r)
 		store_arg_to=run_list
 		;;
 	--run=*)
 		run_list=${opt#--*=} ;;
 	-h|--h|--he|--hel|--help)
 		help=t ;;
 	-v|--v|--ve|--ver|--verb|--verbo|--verbos|--verbose)
 		verbose=t ;;
 	--verbose-only=*)
 		verbose_only=${opt#--*=}
 		;;
 	-q|--q|--qu|--qui|--quie|--quiet)
 		# Ignore --quiet under a TAP::Harness. Saying how many tests
 		# passed without the ok/not ok details is always an error.
 		test -z "$HARNESS_ACTIVE" && quiet=t ;;
 	--with-dashes)
 		with_dashes=t ;;
 	--no-bin-wrappers)
 		no_bin_wrappers=t ;;
 	--no-color)
 		color= ;;
 	--va|--val|--valg|--valgr|--valgri|--valgrin|--valgrind)
 		valgrind=memcheck
 		tee=t
 		;;
 	--valgrind=*)
 		valgrind=${opt#--*=}
 		tee=t
 		;;
 	--valgrind-only=*)
 		valgrind_only=${opt#--*=}
 		tee=t
 		;;
 	--tee)
 		tee=t ;;
 	--root=*)
 		root=${opt#--*=} ;;
 	--chain-lint)
 		GIT_TEST_CHAIN_LINT=1 ;;
 	--no-chain-lint)
 		GIT_TEST_CHAIN_LINT=0 ;;
 	-x)
 		trace=t ;;
 	-V|--verbose-log)
 		verbose_log=t
 		tee=t
 		;;
 	--write-junit-xml)
 		write_junit_xml=t
 		;;
 	--stress)
 		stress=t ;;
 	--stress=*)
 		echo "error: --stress does not accept an argument: '$opt'" >&2
 		echo "did you mean --stress-jobs=${opt#*=} or --stress-limit=${opt#*=}?" >&2
 		exit 1
 		;;
 	--stress-jobs=*)
 		stress=t;
 		stress=${opt#--*=}
 		case "$stress" in
 		*[!0-9]*|0*|"")
 			echo "error: --stress-jobs=<N> requires the number of jobs to run" >&2
 			exit 1
 			;;
 		*)	# Good.
 			;;
 		esac
 		;;
 	--stress-limit=*)
 		stress=t;
 		stress_limit=${opt#--*=}
 		case "$stress_limit" in
 		*[!0-9]*|0*|"")
 			echo "error: --stress-limit=<N> requires the number of repetitions" >&2
 			exit 1
 			;;
 		*)	# Good.
 			;;
 		esac
 		;;
 	*)
 		echo "error: unknown test option '$opt'" >&2; exit 1 ;;
 	esac
+}
+
+# Parse options while taking care to leave $@ intact, so we will still
+# have all the original command line options when executing the test
+# script again for '--tee' and '--verbose-log' below.
+store_arg_to=
+prev_opt=
+for opt
+do
+	if test -n "$store_arg_to"
+	then
+		eval $store_arg_to=\$opt
+		store_arg_to=
+		prev_opt=
+		continue
+	fi
+
+	case "$opt" in
+	--*)
+		parse_option "$opt" ;;
+	-?*)
+		# stacked short options must be fed separately to parse_option
+		for c in $(echo "${opt#-}" | sed 's/./& /g')
+		do
+			parse_option "-$c"
+		done
+		;;
+	*)
+		echo "error: unknown test option '$opt'" >&2; exit 1 ;;
+	esac
 
 	prev_opt=$opt
 done
-- 
2.25.1
Junio C Hamano· Mar 21, 2020, 04:53 UTC · re: Matheus Tavares · lore

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

Matheus Tavares <matheus.bernardino@usp.br> writes:
> +parse_option () {
> +	local opt="$@"

I do not think there is any context in which var="$@" makes sense in shell script (var="$*" is understandable, though).

Did you mean opt=$1 here?
> +# Parse options while taking care to leave $@ intact, so we will still
> +# have all the original command line options when executing the test
> +# script again for '--tee' and '--verbose-log' below.

The phrase "below" no longer makes much sense after moving lines around, does it?

Show 17 quoted lines
> +store_arg_to=
> +prev_opt=
> +for opt
> +do
> +	if test -n "$store_arg_to"
> +	then
> +		eval $store_arg_to=\$opt
> +		store_arg_to=
> +		prev_opt=
> +		continue
> +	fi
> +
> +	case "$opt" in
> +	--*)
> +		parse_option "$opt" ;;
> +	-?*)
> +		# stacked short options must be fed separately to parse_option

Are you calling concatenated short options, e.g. "-abc", as "stacked"? It sounds like a very unusual phrasing, at least to me.

Show 11 quoted lines
> +		for c in $(echo "${opt#-}" | sed 's/./& /g')
> +		do
> +			parse_option "-$c"
> +		done
> +		;;
> +	*)
> +		echo "error: unknown test option '$opt'" >&2; exit 1 ;;
> +	esac
>  
>  	prev_opt=$opt
>  done

I am personally not very enthused (the line counts vs benefit does not feel so great), but as long as it works correctly and maintainable, I won't complain too much.

Matheus Tavares· Mar 21, 2020, 17:27 UTC · re: Junio C Hamano · lore

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

On Sat, Mar 21, 2020 at 1:53 AM Junio C Hamano <gitster@pobox.com> wrote:
Show 9 quoted lines
> Matheus Tavares <matheus.bernardino@usp.br> writes:
>
> > +parse_option () {
> > +	local opt="$@"
>
> I do not think there is any context in which var="$@" makes sense in
> shell script (var="$*" is understandable, though).  
>
> Did you mean opt=$1 here?
Right, it should be $1. Thanks.
Show 6 quoted lines
> > +# Parse options while taking care to leave $@ intact, so we will still
> > +# have all the original command line options when executing the test
> > +# script again for '--tee' and '--verbose-log' below.
>
> The phrase "below" no longer makes much sense after moving lines
> around, does it?

Oh, I thought "below" referred to the later usage of $@ (when --tee or --verbose-log are set). I.e. not the parsing section we moved up, but this one:

elif test -n "$tee"
then
	...
	(GIT_TEST_TEE_STARTED=done ${TEST_SHELL_PATH} "$0" "$@" 2>&1;
Maybe change "below" for "later in the code"?
Show 20 quoted lines
> > +store_arg_to=
> > +prev_opt=
> > +for opt
> > +do
> > +	if test -n "$store_arg_to"
> > +	then
> > +		eval $store_arg_to=\$opt
> > +		store_arg_to=
> > +		prev_opt=
> > +		continue
> > +	fi
> > +
> > +	case "$opt" in
> > +	--*)
> > +		parse_option "$opt" ;;
> > +	-?*)
> > +		# stacked short options must be fed separately to parse_option
>
> Are you calling concatenated short options, e.g. "-abc", as
> "stacked"?  It sounds like a very unusual phrasing, at least to me.

Yeah, I wasn't really sure about the naming for this. Thanks, "concatenated" (or "bundled", as Peff suggested in another reply) does sound better.

Jeff King· Mar 21, 2020, 06:26 UTC · re: Matheus Tavares · lore

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

On Sat, Mar 21, 2020 at 12:07:05AM -0300, Matheus Tavares wrote:
Show 11 quoted lines
> When debugging a test (or a set of tests), it's common to execute it
> with some combination of short options, such as:
> 
> 	$ ./txxx-testname.sh -d -x -i
> 
> In cases like this, CLIs usually allow the short options to be stacked
> in a single argument, for convenience and agility. Let's add this
> feature to test-lib, allowing the above command to be run as:
> 
> 	$ ./txxx-testname.sh -dxi
> 	(or any other permutation, e.g. '-ixd')

Yay. I've grown accustomed to the lack of this feature in the test scripts, but I'll be happy to have it. :)

Most getopt implementations I've seen call this "bundling" rather than "stacking" (I don't care too much either way, but Junio mentioned being confused at the name).

Show 9 quoted lines
> +	case "$opt" in
> +	--*)
> +		parse_option "$opt" ;;
> +	-?*)
> +		# stacked short options must be fed separately to parse_option
> +		for c in $(echo "${opt#-}" | sed 's/./& /g')
> +		do
> +			parse_option "-$c"
> +		done
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.

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. We'd come out of "-rr" parsing with $store_arg_to set, but only grab the first argument. I think I could live with that, considering this is just the test scripts. Fixing it would require store_arg_to becoming a space-separated list.

-Peff
Matheus Tavares Bernardino· Mar 21, 2020, 18:50 UTC · re: Jeff King · lore

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

On Sat, Mar 21, 2020 at 3:26 AM Jeff King <peff@peff.net> wrote:
Show 10 quoted lines
>
> On Sat, Mar 21, 2020 at 12:07:05AM -0300, Matheus Tavares wrote:
>
> > In cases like this, CLIs usually allow the short options to be stacked
> > in a single argument, for convenience and agility. Let's add this
> > feature to test-lib, allowing the above command to be run as:
>
> Most getopt implementations I've seen call this "bundling" rather than
> "stacking" (I don't care too much either way, but Junio mentioned being
> confused at the name).

Yeah, "stacking" wasn't the best word choice. I will replace it by "bundling" then, thanks.

Show 24 quoted lines
>
> > +     case "$opt" in
> > +     --*)
> > +             parse_option "$opt" ;;
> > +     -?*)
> > +             # stacked short options must be fed separately to parse_option
> > +             for c in $(echo "${opt#-}" | sed 's/./& /g')
> > +             do
> > +                     parse_option "-$c"
> > +             done
>
> 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 quite liked this alternative with builtins. It's a little more verbose, but it remains very clear.

Show 11 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

Yes. I just thought, though, that if another "short option with arguments" gets added in the future, the bundle would not work correctly. I don't think we need to be prepared for such a scenario now, but ...

Show 5 quoted lines
> which seems reasonable. But:
>
>   ./t1234-foo.sh -rr 5 6
>
> would get garbled.

... we could prohibit using more than one "short option with arguments" in the same bundle. This would not only solve the problem for "-rr 5 6"[1] but also for the scenario of future new options. And it's quite simple to implement, we just have to check whether $store_arg_to is set before setting it to another value. I'll try that for v2.

[1]: Someone that used '-rr 5 6' might have wanted the script to run *both* tests 5 and 6. But I don't think we need to support that now, since '-r 5 -r 6' doesn't do that as well (instead, the last value overrides all previous ones).

Jeff King· Mar 22, 2020, 06:49 UTC · re: Matheus Tavares Bernardino · lore

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

On Sat, Mar 21, 2020 at 03:50:55PM -0300, Matheus Tavares Bernardino wrote:
Show 12 quoted lines
> > which seems reasonable. But:
> >
> >   ./t1234-foo.sh -rr 5 6
> >
> > would get garbled.
> 
> ... we could prohibit using more than one "short option with
> arguments" in the same bundle. This would not only solve the problem
> for "-rr 5 6"[1] but also for the scenario of future new options. And
> it's quite simple to implement, we just have to check whether
> $store_arg_to is set before setting it to another value. I'll try that
> for v2.

Yeah, I'd be perfectly happy with that. This bundling is a new format that did not exist before, so we are not taking away anything you could previously do. As long as we don't produce a wrong or confusing result (and instead say "don't do that; we don't support it", anybody else is free to come along later and make it work. :)

> [1]: Someone that used '-rr 5 6' might have wanted the script to run
> *both* tests 5 and 6. But I don't think we need to support that now,
> since '-r 5 -r 6' doesn't do that as well (instead, the last value
> overrides all previous ones).

Heh, that's what I assumed "-r 5 -r 6" would do, but I guess it goes to show that I do not use that option very much. :)

-Peff
SZEDER Gábor· Mar 22, 2020, 08:14 UTC · re: Matheus Tavares Bernardino · lore

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

On Sat, Mar 21, 2020 at 03:50:55PM -0300, Matheus Tavares Bernardino wrote:
> [1]: Someone that used '-rr 5 6' might have wanted the script to run
> *both* tests 5 and 6. But I don't think we need to support that now,
> since '-r 5 -r 6' doesn't do that as well (instead, the last value
> overrides all previous ones).

Well, that '-r 5 -r 6' should be written as '-r 5,6', but it shouldn't be terribly difficult to concatenate the args of multiple '-r' options with a comma, I suppose.

But '-rr 5 6' just looks wrong.
Junio C Hamano· Mar 21, 2020, 18:57 UTC · re: Jeff King · lore

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

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.
Johannes Sixt· Mar 21, 2020, 08:55 UTC · re: Matheus Tavares · lore

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

Am 21.03.20 um 04:07 schrieb Matheus Tavares:
Show 18 quoted lines
> +
> +# Parse options while taking care to leave $@ intact, so we will still
> +# have all the original command line options when executing the test
> +# script again for '--tee' and '--verbose-log' below.
> +store_arg_to=
> +prev_opt=
> +for opt
> +do
> +	if test -n "$store_arg_to"
> +	then
> +		eval $store_arg_to=\$opt
> +		store_arg_to=
> +		prev_opt=
> +		continue
> +	fi
> +
> +	case "$opt" in
> +	--*)
Can we please have a case arm for -? here:
	--* | -?)

so that we do not pay the price of many sub-processes when options are _not_ stacked?

Show 15 quoted lines
> +		parse_option "$opt" ;;
> +	-?*)
> +		# stacked short options must be fed separately to parse_option
> +		for c in $(echo "${opt#-}" | sed 's/./& /g')
> +		do
> +			parse_option "-$c"
> +		done
> +		;;
> +	*)
> +		echo "error: unknown test option '$opt'" >&2; exit 1 ;;
> +	esac
>  
>  	prev_opt=$opt
>  done
> 
-- Hannes
Matheus Tavares Bernardino· Mar 21, 2020, 18:55 UTC · re: Johannes Sixt · lore

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

On Sat, Mar 21, 2020 at 5:55 AM Johannes Sixt <j6t@kdbg.org> wrote:
Show 22 quoted lines
>
> Am 21.03.20 um 04:07 schrieb Matheus Tavares:
> >
> > +for opt
> > +do
> > +     if test -n "$store_arg_to"
> > +     then
> > +             eval $store_arg_to=\$opt
> > +             store_arg_to=
> > +             prev_opt=
> > +             continue
> > +     fi
> > +
> > +     case "$opt" in
> > +     --*)
>
> Can we please have a case arm for -? here:
>
>         --* | -?)
>
> so that we do not pay the price of many sub-processes when options are
> _not_ stacked?

Makes sense, thanks. However, using Peff's suggestion[1] for the character iteration already eliminates the need for extra processes. So it will cover this case as well.

[1]: https://lore.kernel.org/git/20200321062611.GA1441446@coredump.intra.peff.net/
Junio C Hamano· Mar 21, 2020, 20:11 UTC · re: Matheus Tavares Bernardino · lore

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

Matheus Tavares Bernardino <matheus.bernardino@usp.br> writes:
> Makes sense, thanks. However, using Peff's suggestion[1] for the
> character iteration already eliminates the need for extra processes.

Even without an extra process, having to strip "-", assign an empty string to $extra, and then strip that empty string from the tail to come up with a single letter in $this, all are consuming cycles. Even though these wasted cycles are now much smaller, having an arm that specifically catches unbundled case and avoid doing anything extra makes the codeflow clear, I would think.

Matheus Tavares· Mar 21, 2020, 19:57 UTC · re: Matheus Tavares · lore

[PATCH v2] test-lib: allow short options to be bundled

When debugging a test (or a set of tests), it's common to execute it with some combination of short options, such as:

	$ ./txxx-testname.sh -d -x -i

In cases like this, CLIs usually allow the short options to be bundled in a single argument, for convenience and agility. Let's add this feature to test-lib, allowing the above command to be run as:

	$ ./txxx-testname.sh -dxi
	(or any other permutation, e.g. '-ixd')
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br>
---
Changes since v1:
- Added a check for bundles containing more than one "option that
  requires args" (e.g. '-rr'), in which case we error-out. We could
  interpret '-rr 1 2' as 'run tests 1 _and_ 2', but the unbundled
  format, '-r 1 -r 2', is not currently interpreted like that (the last
  just overrides the previous). So, for simplicity, let's only forbid
  such bundles for now.
- Used "$1" instead of "$@" to get the argument in parse_option()
- Replaced occurrences of "stacked options" to "bundled options"
- Eliminated spawning of extra processes in the bundled options parser
- s/below/later/ in the parser loop comment, to make it clearer
 t/README      |  3 ++-
 t/test-lib.sh | 62 +++++++++++++++++++++++++++++++++++++++------------
 2 files changed, 50 insertions(+), 15 deletions(-)
Show changes to 2 files +50 −15

t/README, t/test-lib.sh

diff --git a/t/README b/t/README
index 9afd61e3ca..080bc59fc4 100644
--- a/t/README
+++ b/t/README
@@ -69,7 +69,8 @@ You can also run each test individually from command line, like this:
 
 You can pass --verbose (or -v), --debug (or -d), and --immediate
 (or -i) command line argument to the test, or by setting GIT_TEST_OPTS
-appropriately before running "make".
+appropriately before running "make". Short options can be bundled, i.e.
+'-d -v' is the same as '-dv'.
 
 -v::
 --verbose::
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 0ea1e5a05e..dda770ec94 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -78,20 +78,24 @@ then
 	exit 1
 fi
 
-# Parse options while taking care to leave $@ intact, so we will still
-# have all the original command line options when executing the test
-# script again for '--tee' and '--verbose-log' below.
 store_arg_to=
-prev_opt=
-for opt
-do
-	if test -n "$store_arg_to"
+opt_required_arg=
+# $1: option string
+# $2: name of the var where the arg will be stored
+mark_option_requires_arg ()
+{
+	if test -n "$opt_required_arg"
 	then
-		eval $store_arg_to=\$opt
-		store_arg_to=
-		prev_opt=
-		continue
+		echo "error: options that require args cannot be bundled" \
+			"together: '$opt_required_arg' and '$1'" >&2
+		exit 1
 	fi
+	opt_required_arg=$1
+	store_arg_to=$2
+}
+
+parse_option () {
+	local opt="$1"
 
 	case "$opt" in
 	-d|--d|--de|--deb|--debu|--debug)
@@ -101,7 +105,7 @@ do
 	-l|--l|--lo|--lon|--long|--long-|--long-t|--long-te|--long-tes|--long-test|--long-tests)
 		GIT_TEST_LONG=t; export GIT_TEST_LONG ;;
 	-r)
-		store_arg_to=run_list
+		mark_option_requires_arg "$opt" run_list
 		;;
 	--run=*)
 		run_list=${opt#--*=} ;;
@@ -185,12 +189,42 @@ do
 	*)
 		echo "error: unknown test option '$opt'" >&2; exit 1 ;;
 	esac
+}
+
+# Parse options while taking care to leave $@ intact, so we will still
+# have all the original command line options when executing the test
+# script again for '--tee' and '--verbose-log' later.
+for opt
+do
+	if test -n "$store_arg_to"
+	then
+		eval $store_arg_to=\$opt
+		store_arg_to=
+		opt_required_arg=
+		continue
+	fi
 
-	prev_opt=$opt
+	case "$opt" in
+	--*)
+		parse_option "$opt" ;;
+	-?*)
+		# bundled short options must be fed separately to parse_option
+		opt=${opt#-}
+		while test -n "$opt"
+		do
+			extra=${opt#?}
+			this=${opt%$extra}
+			opt=$extra
+			parse_option "-$this"
+		done
+		;;
+	*)
+		echo "error: unknown test option '$opt'" >&2; exit 1 ;;
+	esac
 done
 if test -n "$store_arg_to"
 then
-	echo "error: $prev_opt requires an argument" >&2
+	echo "error: $opt_required_arg requires an argument" >&2
 	exit 1
 fi
 
-- 
2.25.1
Junio C Hamano· Mar 21, 2020, 20:07 UTC · re: Matheus Tavares · lore

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

Matheus Tavares <matheus.bernardino@usp.br> writes:
Show 6 quoted lines
> - Added a check for bundles containing more than one "option that
>   requires args" (e.g. '-rr'), in which case we error-out. We could
>   interpret '-rr 1 2' as 'run tests 1 _and_ 2', but the unbundled
>   format, '-r 1 -r 2', is not currently interpreted like that (the last
>   just overrides the previous). So, for simplicity, let's only forbid
>   such bundles for now.
Makes sense.  I think this is the best we can do at this moment.
Show 5 quoted lines
> +opt_required_arg=
> +# $1: option string
> +# $2: name of the var where the arg will be stored
> +mark_option_requires_arg ()
> +{
"{" on the same line, just like you did for parse_option below.
Show 16 quoted lines
> +	if test -n "$opt_required_arg"
>  	then
> +		echo "error: options that require args cannot be bundled" \
> +			"together: '$opt_required_arg' and '$1'" >&2
> +		exit 1
>  	fi
> +	opt_required_arg=$1
> +	store_arg_to=$2
> +}
> +
> +parse_option () {
> +	local opt="$1"
> ...
> +	case "$opt" in
> +	--*)
> +		parse_option "$opt" ;;
I think J6t's suggestion to the previous round still has merit here.
Show 6 quoted lines
> +	-?*)
> +		# bundled short options must be fed separately to parse_option
> +		opt=${opt#-}
> +		while test -n "$opt"
> +		do
> +			extra=${opt#?}
Take the rest of the string after stripping the first one in $extra ...
> +			this=${opt%$extra}

... and then strip that tail part from the end, which would give the first letter in $this.

> +			opt=$extra

And the next round will use the remainder after taking $this out of the bundled options from the front.

Makes sense.
> +			parse_option "-$this"
> +		done
Thanks
Matheus Tavares Bernardino· Mar 21, 2020, 22:42 UTC · re: Junio C Hamano · lore

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

On Sat, Mar 21, 2020 at 5:07 PM Junio C Hamano <gitster@pobox.com> wrote:
Show 10 quoted lines
>
> Matheus Tavares <matheus.bernardino@usp.br> writes:
>
> > +opt_required_arg=
> > +# $1: option string
> > +# $2: name of the var where the arg will be stored
> > +mark_option_requires_arg ()
> > +{
>
> "{" on the same line, just like you did for parse_option below.
Thanks. Will fix.
Show 18 quoted lines
> > +     if test -n "$opt_required_arg"
> >       then
> > +             echo "error: options that require args cannot be bundled" \
> > +                     "together: '$opt_required_arg' and '$1'" >&2
> > +             exit 1
> >       fi
> > +     opt_required_arg=$1
> > +     store_arg_to=$2
> > +}
> > +
> > +parse_option () {
> > +     local opt="$1"
> > ...
> > +     case "$opt" in
> > +     --*)
> > +             parse_option "$opt" ;;
>
> I think J6t's suggestion to the previous round still has merit here.

Yeah, I agree with your last reply that it makes the codeflow clearer. I'll wait a bit to see if anyone else has other comments about this iteration and then send v3 with both changes.

Thanks.
Matheus Tavares· Mar 22, 2020, 15:58 UTC · re: Matheus Tavares · lore

[PATCH v3] test-lib: allow short options to be bundled

When debugging a test (or a set of tests), it's common to execute it with some combination of short options, such as:

	$ ./txxx-testname.sh -d -x -i

In cases like this, CLIs usually allow the short options to be bundled in a single argument, for convenience and agility. Let's add this feature to test-lib, allowing the above command to be run as:

	$ ./txxx-testname.sh -dxi
	(or any other permutation, e.g. '-ixd')
Note: Short options that require an argument can also be used in a
bundle, in any position. So, for example, '-r 5 -x', '-xr 5' and '-rx 5'
are all valid and equivalent. A special case would be having a bundle
with more than one of such options. To keep things simple, this case is
not allowed for now. This shouldn't be a major limitation, though, as
the only short option that requires an argument today is '-r'. And
concatenating '-r's as in '-rr 5 6' would probably not be very
practical: its unbundled format would be '-r 5 -r 6', for which test-lib
currently considers only the last argument. Therefore, if '-rr 5 6' were
to be allowed, it would have the same effect as just typing '-r 6'.
Note: the test-lib currently doesn't support '-r5', as an alternative
for '-r 5', so the former is not supported in bundles as well.
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br>
---
Changes since v2:
- Fixed style in mark_option_requires_arg(), moving "{" to the same line
- In the main options parser loop, joined long options and unbundled
  short options in the same case arm, as suggested by J6t. This provides
  a clearer codeflow.
- Summarized, in the commit message, the approach chosen on bundling
  options that require args. Since this was an important point in the
  last rounds, I thought it would be good to include our decisions (and
  justification) in the commit body.
 t/README      |  3 ++-
 t/test-lib.sh | 61 +++++++++++++++++++++++++++++++++++++++------------
 2 files changed, 49 insertions(+), 15 deletions(-)
Show changes to 2 files +49 −15

t/README, t/test-lib.sh

diff --git a/t/README b/t/README
index 9afd61e3ca..080bc59fc4 100644
--- a/t/README
+++ b/t/README
@@ -69,7 +69,8 @@ You can also run each test individually from command line, like this:
 
 You can pass --verbose (or -v), --debug (or -d), and --immediate
 (or -i) command line argument to the test, or by setting GIT_TEST_OPTS
-appropriately before running "make".
+appropriately before running "make". Short options can be bundled, i.e.
+'-d -v' is the same as '-dv'.
 
 -v::
 --verbose::
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 0ea1e5a05e..a6178e9fac 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -78,20 +78,23 @@ then
 	exit 1
 fi
 
-# Parse options while taking care to leave $@ intact, so we will still
-# have all the original command line options when executing the test
-# script again for '--tee' and '--verbose-log' below.
 store_arg_to=
-prev_opt=
-for opt
-do
-	if test -n "$store_arg_to"
+opt_required_arg=
+# $1: option string
+# $2: name of the var where the arg will be stored
+mark_option_requires_arg () {
+	if test -n "$opt_required_arg"
 	then
-		eval $store_arg_to=\$opt
-		store_arg_to=
-		prev_opt=
-		continue
+		echo "error: options that require args cannot be bundled" \
+			"together: '$opt_required_arg' and '$1'" >&2
+		exit 1
 	fi
+	opt_required_arg=$1
+	store_arg_to=$2
+}
+
+parse_option () {
+	local opt="$1"
 
 	case "$opt" in
 	-d|--d|--de|--deb|--debu|--debug)
@@ -101,7 +104,7 @@ do
 	-l|--l|--lo|--lon|--long|--long-|--long-t|--long-te|--long-tes|--long-test|--long-tests)
 		GIT_TEST_LONG=t; export GIT_TEST_LONG ;;
 	-r)
-		store_arg_to=run_list
+		mark_option_requires_arg "$opt" run_list
 		;;
 	--run=*)
 		run_list=${opt#--*=} ;;
@@ -185,12 +188,42 @@ do
 	*)
 		echo "error: unknown test option '$opt'" >&2; exit 1 ;;
 	esac
+}
+
+# Parse options while taking care to leave $@ intact, so we will still
+# have all the original command line options when executing the test
+# script again for '--tee' and '--verbose-log' later.
+for opt
+do
+	if test -n "$store_arg_to"
+	then
+		eval $store_arg_to=\$opt
+		store_arg_to=
+		opt_required_arg=
+		continue
+	fi
 
-	prev_opt=$opt
+	case "$opt" in
+	--*|-?)
+		parse_option "$opt" ;;
+	-?*)
+		# bundled short options must be fed separately to parse_option
+		opt=${opt#-}
+		while test -n "$opt"
+		do
+			extra=${opt#?}
+			this=${opt%$extra}
+			opt=$extra
+			parse_option "-$this"
+		done
+		;;
+	*)
+		echo "error: unknown test option '$opt'" >&2; exit 1 ;;
+	esac
 done
 if test -n "$store_arg_to"
 then
-	echo "error: $prev_opt requires an argument" >&2
+	echo "error: $opt_required_arg requires an argument" >&2
 	exit 1
 fi
 
-- 
2.25.1
Junio C Hamano· Mar 23, 2020, 20:18 UTC · re: Matheus Tavares · lore

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

Matheus Tavares <matheus.bernardino@usp.br> writes:
Show 5 quoted lines
> Helped-by: Jeff King <peff@peff.net>
> Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br>
> ---
>
> Changes since v2:
Queued.  Thanks.

← back to recent threads