t8002: fix ambiguous printf conversion specifications

In e7fb2ca (builtin/blame: fix out-of-bounds write with blank
boundary commits, 2025-01-10), we have introduced two new tests that
expect a certain amount of padding. This padding is generated via
printf using the "%0.s" conversion specification. That directive is
ambiguous because it might be interpreted as field width (most shells)
or 0-padding flag for numeric fields (coreutils).

Fix this issue by using "%${N}s" instead, which is already being
used in other tests (i.e. t5300, t0450) and is unambiguous.

Helped-by: Patrick Steinhardt <[email protected]>
Signed-off-by: Jan Palus <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>

Author: jpalus

t/t8002-blame.sh

@@ -138,15 +138,15 @@ test_expect_success 'blame --abbrev -b truncates the blank boundary' '
 	# Note that `--abbrev=` always gets incremented by 1, which is why we
 	# expect 11 leading spaces and not 10.
 	cat >expect <<-EOF &&
-	$(printf "%0.s " $(test_seq 11)) (<[email protected]> 2005-04-07 15:45:13 -0700 1) abbrev
+	$(printf "%11s" "") (<[email protected]> 2005-04-07 15:45:13 -0700 1) abbrev
 	EOF
 	git blame -b --abbrev=10 ^HEAD -- abbrev.t >actual &&
 	test_cmp expect actual
 '
 
 test_expect_success 'blame with excessive --abbrev and -b culls to hash length' '
 	cat >expect <<-EOF &&
-	$(printf "%0.s " $(test_seq $hexsz)) (<[email protected]> 2005-04-07 15:45:13 -0700 1) abbrev
+	$(printf "%${hexsz}s" "") (<[email protected]> 2005-04-07 15:45:13 -0700 1) abbrev
 	EOF
 	git blame -b --abbrev=9000 ^HEAD -- abbrev.t >actual &&
 	test_cmp expect actual