Re: tr and automake

[James Laird]

On Tue, 11 Oct 2005, Ralf Wildenhues wrote:
> Hi James,
> 
> * James Laird wrote on Mon, Oct 10, 2005 at 08:11:31PM CEST:
> > 
> > My package (hdf.ncsa.uiuc.edu/HDF5) has historically tested that the tr 
> > utility works correctly at configure time.  Apparently there are two 
> > kinds of tr which expect slightly different syntax for their input.
> 
> What are the exact differences?  What does "the other tr" do in the test
> you quoted?

It's a difference in syntax.  This is what I got from the sysadmin:

>COMPATIBILITY
>      System V has historically implemented character ranges using
>      the syntax ``[c-c]'' instead of the ``c-c'' used by historic
>      BSD implementations and standardized  by  POSIX.   System  V
>      shell  scripts should work under this implementation as long
>      as the range is intended to map in another range,  i.e.  the
>      command  ``tr  [a-z]  [A-Z]''  will  work as it will map the
>      ``[''  character  in  string1  to  the  ``[''  character  in
>      string2.   However,  if  the  shell  script  is  deleting or
>      squeezing characters as in the command ``tr -d [a-z]'',  the
>      characters  ``['' and ``]'' will be included in the deletion
>      or compression list which would not have happened  under  an
>      historic System V implementation.  Additionally, any scripts
>      that depended on the sequence ``a-z'' to represent the three
>      characters  ``a'', ``-'' and ``z'' will have to be rewritten
>      as ``a\-z''.  In order to get POSIX.2 behavior,  the  POSIX2
>      environment  variable  should be set, otherwise the historic
>      Svstem V behavior is gotten.


> > We have now encountered a platform where setting the path to point to the 
> > "correct" tr confuses the path to some libraries that the compiler needs.  
> 
> Let me guess: some w32 platform?

Solaris 8, 9, and 10, actually.

> In general, two differences between execution from within `configure'
> and outside are likely candidates for different behavior: setting of
> PATH, and locale settings.  Just FYI.

Right.  Our problem isn't with configure finding one tr and the user
finding another, but with configure expecting one tr and the PATH being
set to point to another.  Setting the PATH to point to the "correct" tr
works on most platforms, but this time it also confused the path to
something else, so we're looking for a better solution.

> > What we'd like to do is to set an environment variable for tr rather than 
> > changing the global path.  We can change our own configure tests, but it 
> > looks like aclocal.m4 uses tr by name.
> 
> Try using AC_PATH_PROG instead of AC_CHECK_PROG.  The program `aclocal'
> has little business with tests that end up inside the file `aclocal.m4':
> it merely collects all needed macros into that file.

You're right; I think the macros in question may come from libtool rather 
than automake.  They seem to be setting sys_lib_search_path_spec.

> > If aclocal is happy with either version of tr, so much the better.  If
> > not, I'd like to suggest that it replace "tr" with the environment
> > variable "$TR" and add a test in configure to ensure that the correct
> > version of tr is being used.
> 
> Can't see where aclocal makes special use of "tr", see above.
>
> I hope this random collection of comments helps you a bit.  If not,
> please be more specific in what does not work for you (including error
> output, used tools with versions, and, if possible, a small example to
> reproduce the problem).  I have not understood what the problem is you
> are describing.

Sorry if my explanation left a little to be desired; I'm trying to 
maintain legacy tests on a platform that I personally don't have access 
to.  :)

The symptom of the problem is that the test (included below) fails.  
Commenting out the test and using the "wrong" version of tr (the two 
versions are explained above) may or may not have repercussions; the build 
had a few odd issues but succeeded, but some issues were expected since it 
was a new platform.

At any rate, since we know there are two different versions of tr, we'd
like to enforce that users have the same tr utility that we test with; we
have a test to enforce this, but can't change the tests in aclocal.m4 that
we didn't write (and which apparently came from libtool?).

Should I just forward this conversation to a libtool list rather than an 
automake list?

The help is much appreciated,
   James

> Cheers,
> Ralf
> 
> > Such a test might look like this:
> > 
> > AC_MSG_CHECKING([if tr works])
> > if test "X${TR}" = "X"; then
> >   TR=tr
> > fi
> > TR_TEST="`echo Test | ${TR} 'a-z,' 'A-Z '`"
> > if test "${TR_TEST}" != "TEST"; then
> >   AC_MSG_ERROR([tr program doesn't work])
> > else
> >   AC_MSG_RESULT([yes])
> > fi
>