tests: avoid a spurious failure with Solaris /bin/sh

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.lattarini@gmail.com>

diff --git a/t/missing3.sh b/t/missing3.sh
index 27dcd12..b2cacf9 100755 (executable)
--- 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 :)