Re: [PATCH 3/6] t: local VAR="VAL" (quote positional parameters)

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 8, 2024, 17:23 UTC
Message-ID: <xmqqil0rdazm.fsf@gitster.g>
In-Reply-To: <ZhQNq4ITp68ikVVy@tanuki>

Patrick Steinhardt <ps@pks.im> writes:

Show 32 quoted lines

> On Fri, Apr 05, 2024 at 05:08:59PM -0700, Junio C Hamano wrote:
>> Future-proof test scripts that do
>> 
>> 	local VAR=VAL
>> 
>> without quoting VAL (which is OK in POSIX but broken in some shells)
>> that is a positional parameter, e.g. $4.
>> 
>> Signed-off-by: Junio C Hamano <gitster@pobox.com>
>> ---
>>  t/lib-parallel-checkout.sh | 2 +-
>>  t/t2400-worktree-add.sh    | 2 +-
>>  t/t4210-log-i18n.sh        | 4 ++--
>>  t/test-lib-functions.sh    | 2 +-
>>  4 files changed, 5 insertions(+), 5 deletions(-)
>> 
>> diff --git a/t/lib-parallel-checkout.sh b/t/lib-parallel-checkout.sh
>> index acaee9cbb6..8324d6c96d 100644
>> --- a/t/lib-parallel-checkout.sh
>> +++ b/t/lib-parallel-checkout.sh
>> @@ -20,7 +20,7 @@ test_checkout_workers () {
>>  		BUG "too few arguments to test_checkout_workers"
>>  	fi &&
>>  
>> -	local expected_workers=$1 &&
>> +	local expected_workers="$1" &&
>>  	shift &&
>
> I was wondering a bit why this is a problem in t0610, but not over here.
> As far as I understand it these statements are fine in practice because
> the expanded values cannot be split, right? So if "$1" expanded to
> something with spaces in between things would start to break.

Correct.

> In any case, changing all of these to be quoted feels like the right
> thing to do regardless of whether or not it happens to work with the
> current values of "$1". Otherwise it's simply a confusing failure
> waiting to happen.

Again, agreed.  That is where my "Future-proof" comes from.

The true objective of this change is so that the last patch does not have to learn too much exceptions ;-) As long as expected_workers is expected to be a number (an unbroken sequence of digits), even if we add more callers to this helper in the future, $1 we see here is expected to be $IFS safe. So in that sense my "future-proof" is a white lie.