Travis Bauer <trbauer@indiana.edu> writes:
> I have tr version 1.22 (GNU texutils). It is located in /usr/bin, and is
> found by my login shell (cshrc).
That was a weak theory, but worth checking ...
> How could I check the locale setting?
echo $LOCALE I think --- someone who actually uses non-ASCII locales
would be a better reference than I. But the critical bit here is the
part of configure.in that's trying to find the right platform-specific
tr invocation:
dnl Check tr flags to convert from lower to upper case
TRSTRINGS="`echo ABCdef | $TR '[[a-z]]' '[[A-Z]]' 2>/dev/null | grep ABCDEF`"
TRCLASS="`echo ABCdef | $TR '[[:lower:]]' '[[:upper:]]' 2>/dev/null | grep ABCDEF`"
if test "$TRSTRINGS" = "ABCDEF"; then
TRARGS="'[[a-z]]' '[[A-Z]]'"
elif test "$TRCLASS" = "ABCDEF"; then
TRARGS="'[[:lower:]]' '[[:upper:]]'"
else
AC_MSG_ERROR("Can\'t find method to convert from upper to lower case with tr")
fi
(hmm ... the error message is exactly backwards from what's actually
being tested, isn't it? Minor point but...) Anyway, try these out
and see what's happening with your 'tr'. Note that the apparently
doubled square brackets are a quoting artifact of autoconf --- you
should actually test [a-z] and so on, not [[a-z]].
The really silly bit is that configure.in has several other invocations
of tr that pay no attention at all to the results so painfully extracted
(or mis-extracted) here. So it kinda looks to me like we could rip out
this test, hardwire the translation as
tr '[a-z]' '[A-Z]'
and be no worse off. Does anyone recall why this test is in there to
begin with?
regards, tom lane