Subject: Re: [PATCH v4 12/12] t: detect errors outside of test cases

From: "brian m. carlson" <[email-masked]>
Date: Sat, 18 Apr 2026 19:17:43 +0000

On 2026-04-18 at 12:17:10, Ben Knoble wrote:
> 
> > Le 18 avr. 2026 à 02:50, Jeff King <[email-masked]> a écrit :
> > Thinking on this a little more, it is a shame we cannot easily enable
> > this for dash. That would hit most CI jobs, but also the local builds of
> > most developers. And finding problems early and locally often saves a
> > lot of time versus finding them in CI.
> > 
> > Unfortunately I could not find a way to detect whether we are running
> > dash at all, let alone a recent version. But what if we let the user
> > tell us? Something like:
> 
> I was just wishing for similar! I imagine it would be useful for folks
> who occasionally test Zsh’s POSIX mode and want to see how it handles
> -e

I hard-coded this on with a bunch of shells in Debian unstable using the
below script.  zsh, busybox, and dash passed, while mksh, lksh, and posh
failed.  (The latter are all pdksh variants, I believe, so they are an
important set of shells to consider.)

Note that the script symlinks the shell to `sh` so that everyone will be
on their best POSIX behaviour.

----
#!/bin/sh

dir=$(mktemp -d)
trap 'rm -fr "$dir"' EXIT

sh="$1"
ln -sf "$sh" "$dir/sh"

make -j12 all && (cd t && GIT_PROVE_OPTS=-j12 GIT_TEST_DEFAULT_HASH=sha256 PATH="$dir:$PATH" SHELL_PATH="$dir/sh" make prove)
----

Having said that, I actually think that mksh may be right in at least
one case.  For instance, this diff seems required for mksh to pass t1410
and I believe this is actually the right thing to do:

----
diff --git a/t/t1410-reflog.sh b/t/t1410-reflog.sh
index ce71f9a30a..f289fc11e9 100755
--- a/t/t1410-reflog.sh
+++ b/t/t1410-reflog.sh
@@ -23,7 +23,7 @@ check_have () {
 }
 
 check_fsck () {
-	git fsck --full >fsck.output
+	git fsck --full >fsck.output || true
 	case "$1" in
 	'')
 		test_must_be_empty fsck.output ;;
----

I haven't checked the other cases under mksh, but I think it may be a
fruitful source of things to look at.  And if you find a bug, I'm sure
the maintainer would happily accept a bug report in the Debian BTS.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA