Re: [PATCH v2 0/8] git-submodule.sh: improve parsing of options

Roy Eldar <royeldar0@gmail.com> writes:

After reading this, it was confusing to see [1/8] still doing "1 or empty" boolean, only to be further modified in [7/8]. We prefer to see a single series stumbling in the middle and changing the course.

Just a tangent.

While a simple wrapper script is generally easier to debug and read if $verbose variable's value is "--verbose" or "", there is a case where following this pattern is not a good idea. If an option we are eventually going to give to the underlying command takes a value, the value can contain whitespace, and the option and its value need to be passed as two separate arguments, it is less error prone to use the "variable only contains the value" approach.

Imagine that submodule--helper takes a "--foo" option with a greeting message like "hello world" in such a way. We'd want to trigger it this way:

	git submodule--helper --foo "hello world"

as we are assuming that for some reason we need to pass them as two words, and

	git submodule--helper --foo="hello world"

is not an option. In such a case, a wrapper script that takes such an optional parameter in $foo is easier to write like so

	# parse
	foo=
	while ...
	do
                case "$opt" in
                --foo=*)	foo="${1#--foo=}" ;;
                --foo)		foo=${2?"--foo without value"};	shift ;;
		...
		esac
		shift
	done

	# interpolate
	git submodule--helper ${foo:+--foo "$foo"}

in order to avoid the value given to the option split at $IFS whitespace. With foo='--foo="hello world"', passing it to the underlying command would involve use of eval and becomes error prone.

I am assuming (but I don't use "git submodule" very often, so my assumption may be way off) that there is no such variable we need to pass, but if not, we may need to reconsider and use the "variable has only value of the option" for at least some of them.