[FYI] {maint} tests: avoid spurious failure of 't/uninstall-fail.sh' on OpenIndiana

[Stefano Lattarini]

On current OpenIndiana (based on what once was OpenSolaris 11), the shell
/bin/sh (which, differently from what happens on Solaris, is a true POSIX
shell, thus worthy of consideration) somehow manages to "eat" the
error message from 'rm' when that fails to remove a file due to lacking
permission on the parent directory:

  $ /bin/sh -c "cd unwritable-dir || { echo OOPS; exit 1; }; rm -f foo"
  $ echo rc = $?
  rc = 1
  $ /bin/bash -c "cd unwritable-dir || { echo OOPS; exit 1; }; rm -f foo"
  rm: foo not removed: Permission denied
  $ echo rc = $?
  rc = 2
  $ /bin/sh -c "cd unwritable-dir || { echo OOPS; exit 1; }; env rm -f foo"
  rm: foo not removed: Permission denied
  $ echo rc = $?
  rc = 2

That is probably due to an improper optimization, that is, the shell tries
to be smart and remove the file itself instead of invoking 'rm', but fails
spectacularly in the attempt.

* t/uninstall-fail.sh: The just-described bug was causing a spurious
failure in this test case.  Cater to thus situation, by relaxing the
test when a faulty shell is detected.  And while at it, fix and improve
an unrelated comment.

Signed-off-by: Stefano Lattarini <address@hidden>
---
 t/uninstall-fail.sh | 14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/t/uninstall-fail.sh b/t/uninstall-fail.sh
index 230832c..510c968 100755
--- a/t/uninstall-fail.sh
+++ b/t/uninstall-fail.sh
@@ -28,9 +28,14 @@ chmod a-w d || skip "cannot make directories unwritable"
 
 # On Solaris 10, if '/bin/rm' is run with the '-f' option, it doesn't
 # print any error message when failing to remove a file (due to e.g.,
-# "Permission denied").  Yikes.  We'll cater to this incompatibility
-# by relaxing a test below if a faulty 'rm' is detected.
-st=0; rm -f d/f 2>stderr || st=$?
+# "Permission denied").  And it gets weirder.  On OpenIndiana 11, the
+# /bin/sh shell (in many respects a decent POSIX shell) seems to somehow
+# "eat" the error message from 'rm' in some situation, although the 'rm'
+# utility itself correctly prints it when invoked from (say) 'env' or
+# 'bash'.  Yikes.
+# We'll cater to these incompatibilities by relaxing a test below if
+# a faulty shell or 'rm' program is detected.
+st=0; $SHELL -c 'rm -f d/f' 2>stderr || st=$?
 cat stderr >&2
 test $st -gt 0 || skip_ "can delete files from unwritable directories"
 if grep 'rm:' stderr; then
@@ -53,7 +58,8 @@ $ACLOCAL
 $AUTOMAKE
 $AUTOCONF
 
-# Make it harder to experience false postives when grepping error messages.
+# Weird name, to make it harder to experience false positives when
+# grepping error messages.
 inst=__inst-dir__
 
 ./configure --prefix="$(pwd)/$inst"
-- 
1.7.12.rc0