stumped on a simple autoconf/m4/sh problem

[G. Branden Robinson]

[please reply to the groff@ as well; I am not subscribed to autoconf@]

Apparently I am having a moment of dumb.

In preparation for a 1.24 release, I am trying to get groff building on
Solaris 10, which has yet again received a stay of execution from
Oracle.[1]

https://blogs.oracle.com/solaris/post/new-end-date-of-extended-support-for-oracle-solaris-10-and-113

One of Solaris 10's many problems is its rotten `tr` implementation,
which is non-conforming with POSIX and writes wretchedly anonymous and
unhelpful diagnostic messages as well.  On the bright side, if one has
GNU coreutils installed, providing `gtr`, you can use that and be happy.
And that is what the FSF France's compiler farm has done.

So that's what I'm trying to make a groff build do.

AC_DEFUN([GROFF_FIND_POSIX_CONFORMING_TR], [
  AC_MSG_CHECKING([for a 'tr' that supports POSIX character classes])
  TR=no
  for cmd in tr gtr
  do
    if test \
      "`printf 'a\tb' | $cmd '[[:cntrl:]]' '[[ *]]' 2> /dev/null`" \
      = 'a b'
    then
      TR=$cmd
      break
    fi
  done
  if test $TR != no
  then
    AC_MSG_RESULT([$TR])
    AC_SUBST([TR])
  else
    AC_MSG_RESULT([(none)])
    AC_MSG_NOTICE([A 'tr' command that supports POSIX character \
classes was not found.

Some 'hdtbl' example documents will fail to generate, and some test
scripts exercised by 'make check' will also fail.
    ])
  fi
])

Please excuse any non-idiomatic conventions in the foregoing; I am still
acquiring seasoning as an Autoconf macro writer.

The problem is that the test exercising `$cmd` succeeds on Solaris 10
when it should not.

No quoting screwups leap out at me:

$ sed -n '31492,31525p' configure
  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for a 'tr' that supports 
POSIX character classes" >&5
$as_echo_n "checking for a 'tr' that supports POSIX character classes... " >&6; 
}
  TR=no
  for cmd in tr gtr
  do
    if test \
      "`printf 'a\tb' | $cmd '[:cntrl:]' '[ *]' 2> /dev/null`" \
      = 'a b'
    then
      TR=$cmd
      break
    fi
  done
  if test $TR != no
  then
    { $as_echo "$as_me:${as_lineno-$LINENO}: result: $TR" >&5
$as_echo "$TR" >&6; }

  else
    { $as_echo "$as_me:${as_lineno-$LINENO}: result: (none)" >&5
$as_echo "(none)" >&6; }
    { $as_echo "$as_me:${as_lineno-$LINENO}: A 'tr' command that supports POSIX 
character \
classes was not found.

Some 'hdtbl' example documents will fail to generate, and some test
scripts exercised by 'make check' will also fail.
    " >&5
$as_echo "$as_me: A 'tr' command that supports POSIX character \
classes was not found.

Some 'hdtbl' example documents will fail to generate, and some test
scripts exercised by 'make check' will also fail.
    " >&6;}
  fi

But here's what happens...

checking for a 'tr' that supports POSIX character classes... tr

Yikes!

When I run equivalent code from the shell prompt:

if test "`printf 'a\tb' | tr '[:cntrl:]' '[ *]' 2> /dev/null`" = 'a b'; then 
echo good tr; else echo bad tr; fi
printf 'a\tb' | tr '[:cntrl:]' '[ *]' 2> /dev/null
bad tr

(That's bash-3.2, essential survival gear on a Solaris 10 system.)

$ if test "`printf 'a\tb' | tr '[:cntrl:]' '[ *]' 2> /dev/null`" = 'a b'; then 
echo good tr; else echo bad tr; fi
bad tr

(That's Solaris 10 /bin/sh, the World's Worst Living Shell.)

So the "good tr" branch is being taken in the configure script, but not
in vivo at a shell prompt.  I can't explain this.

Would someone kindly point out my rookie mistake?  My eyes are blind.

Regards,
Branden

[1] We have unconfirmed report that this is due to Larry Ellison
    exercising a personal vendetta against me.

signature.asc
Description: PGP signature