Jeff King <[email protected]> writes:
> +# The message, filename, and contents strings are evaluated by the shell
> inside
> +# double-quotes, with $n set to the current commit number. So you can do:
> +#
> +# test_commit_bulk --filename=file --contents='modification $n'
> +#
> +# to have every commit touch the same file, but with unique content. Spaces
> are
> +# OK, but you must escape any metacharacters (like backslashes or
> +# double-quotes) you do not want expanded.
Nice.
> +test_commit_bulk () {
> + indir=
> + ...
> + while test $# -gt 0
> + do
> + case "$1" in
> + -C)
> + indir=$2
> + shift
> + ;;
> + ...
> + esac
> + shift
> + done
> + total=$1
> +
> + in_dir=${indir:+-C "$indir"}
I thought that this assignment to $in_dir would be unnecessary if we
parsed -C directly into it, i.e.
...
-C)
in_dir="-C $indir"
shift
;;
...
but you probably could pass -C '' to defeat an $in_dir that was set
earlier by using a separate variable?
Messages and other stuff are made `eval`-safe, but this one does not
care much about quoting, which made me curious.
Reading further, though, I do not seem to see where this variable is
referred to, and that is the answer to my puzzlement. This must be
a leftover that was written once before but no longer is used. We
can remove $in_dir while keeping the initialization and assignment
to $indir as-is, I think.
All uses of $indir in the remainder of the function look $IFS-safe,
which is good.
