The /bin/sh shell on Solaris is dumb enough not to set the exit status to 127 after the execution of a non-existing command is attempted:
$ /bin/sh -c 'nonesuch'; echo stat = $? /bin/sh: nonesuch: not found stat = 1 This means that the missing script, when run through that shell, cannot discriminate between a real failure of a maintainer tool and a failure due to its absence. This is not a big deal in practice (especially because all the 'missing' invocations in our Makefiles are done with $(SHELL), and that is almost surely set by configure to a proper POSIX shell), but was causing an annoying failure in our testsuite. Fix it. * t/missing3.sh: If 'missing' is run with a /bin/sh shell suffering from the just-described bug, skip the check that would spuriously fail due to that bug. Signed-off-by: Stefano Lattarini <stefano.lattar...@gmail.com> --- t/missing3.sh | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/t/missing3.sh b/t/missing3.sh index 27dcd12..b2cacf9 100755 --- a/t/missing3.sh +++ b/t/missing3.sh @@ -34,7 +34,14 @@ run_cmd () run_cmd ./missing b7cb8259 --version && exit 1 grep WARNING stderr && exit 1 run_cmd ./missing b7cb8259 --grep && exit 1 -grep 'WARNING:.*missing on your system' stderr + +if test x"$am_test_prefer_config_shell" != x"yes"; then + # The /bin/sh from Solaris 10 is a spectacular failure. After a failure + # due to a "command not found", it sets '$?' to '1'. + if (st=0; /bin/sh -c 'no--such--command' || st=$?; test $st -eq 127); then + grep 'WARNING:.*missing on your system' stderr + fi +fi # missing itself it known to exist :) -- 1.7.10.4
