Add tr to common programs

View: New views
6 Messages — Rating Filter:   Alert me  

Add tr to common programs

by Eric Blake :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

A bug report on the autoconf list recently reported that autoconf has been
producing configure files for several years now with a dependence on
tr[1], even though tr is not listed in the set of safe programs[2].  Since
there have been no bug reports about an inability to configure packages
because of the use of tr, I propose adding it to the set of approved
programs (note that autoconf already lists some portability issues to be
aware of when using tr[3]).

[1] http://lists.gnu.org/archive/html/autoconf/2008-10/msg00124.html
[2]
http://www.gnu.org/software/automake/manual/standards.html#Utilities-in-Makefiles
[3]
http://www.gnu.org/software/autoconf/manual/autoconf.html#Limitations-of-Usual-Tools,
under tr

2008-11-04  Eric Blake  <ebb9@...>

        * doc/make-stds.texi (Utilities in Makefiles): Add tr.

diff --git a/doc/make-stds.texi b/doc/make-stds.texi
index bd4df50..98e5e86 100644
--- a/doc/make-stds.texi
+++ b/doc/make-stds.texi
@@ -161,7 +161,7 @@ Utilities in Makefiles

 @example
 awk cat cmp cp diff echo egrep expr false grep install-info
-ln ls mkdir mv pwd rm rmdir sed sleep sort tar test touch true
+ln ls mkdir mv pwd rm rmdir sed sleep sort tar test touch tr true
 @end example

 Compression programs such as @code{gzip} can be used in the

--
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9@...



Re: Add tr to common programs

by Ralf Wildenhues :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hello Eric,

* Eric Blake wrote on Tue, Nov 04, 2008 at 02:21:05PM CET:
> A bug report on the autoconf list recently reported that autoconf has been
> producing configure files for several years now with a dependence on
> tr[1],

I didn't see it, where exactly would that be?

> 2008-11-04  Eric Blake  <ebb9@...>
>
> * doc/make-stds.texi (Utilities in Makefiles): Add tr.

I'd be in support of this but only iff there is a very prominent big
warning for the various portability hassles with tr which are *not*
mentioned in the Autoconf manual.  IIRC this was the reason to keep
it out of GCS.

The SUSv3 has some good hints in the informative section of the 'tr'
description.  I'm not sure whether everyone reads it, but at least
pointing to it would seem prudent.

Cheers,
Ralf



Re: Add tr to common programs

by Karl Berry :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

    A bug report on the autoconf list recently reported that autoconf has been
    producing configure files for several years now with a dependence on
    tr[1]
    [1] http://lists.gnu.org/archive/html/autoconf/2008-10/msg00124.html

The config.status for texinfo uses tr in one place, as far as I can see:

      expr "X$arg" : "X\\(.*\\)" | tr -d "$as_nl"

Not for $as_cr as your message suggests.  Is that a recent change?
Are there other uses?

Anyway, I am surprised that your experience is that tr is more portable
than awk for this.  I've never thought that \r and the like were
portable across tr's, although I haven't made a study of it lately.  If
\r is not portable across awk's, how about \015?  It is hard to imagine
an awk that doesn't support that ...

Adding tr for the sake of this one small task seems a bit troublesome to
me, per Ralf's mail.  Not that I'm saying no, but let's discuss ...

karl



Re: Add tr to common programs

by Eric Blake :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Karl Berry on 11/4/2008 4:33 PM:

Hi Karl, Ralf,

>     A bug report on the autoconf list recently reported that autoconf has been
>     producing configure files for several years now with a dependence on
>     tr[1]
>     [1] http://lists.gnu.org/archive/html/autoconf/2008-10/msg00124.html
>
> The config.status for texinfo uses tr in one place, as far as I can see:
>
>       expr "X$arg" : "X\\(.*\\)" | tr -d "$as_nl"
>
> Not for $as_cr as your message suggests.  Is that a recent change?
> Are there other uses?

On a whim, I picked ftp://ftp.gnu.org/pub/gnu/texinfo/texinfo-4.5.tar.gz,
dating back to 2/15/2004.

$ grep -n ' tr ' texinfo-4.5/configure
5576:      jm_tr_func=HAVE_DECL_`echo $jm_func | tr
abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`
8370:    ac_prog=`($CC -print-prog-name=ld) 2>&5 | tr -d '\015'` ;;
9333:    am_cv_proto_iconv=`echo "$am_cv_proto_iconv" | tr -s ' ' | sed -e
's/( /(/'`

In other words, tr has been used in configure scripts long before this
particular autoconf patch to config.status.  It was just that this recent
patch raised the issue of whether tr should be used at all.

>
> Anyway, I am surprised that your experience is that tr is more portable
> than awk for this.  I've never thought that \r and the like were
> portable across tr's, although I haven't made a study of it lately.

Nope, \r is not portable to Solaris /usr/ucb/tr.  \015 is portable,
however (even in EBCDIC, it still resolves to carriage return); in
Autoconf's particular use-case of \015, with $as_cr, the script
intentionally decays to a no-op replacement if \015 is not carriage return
due to some other weird encoding.

>  If
> \r is not portable across awk's, how about \015?  It is hard to imagine
> an awk that doesn't support that ...

The whole reason that autoconf recently had to add support for tr \015 is
that we already had problems trying either \015 or \r in awk.  And literal
^M in the file was also problematic.

>
> Adding tr for the sake of this one small task seems a bit troublesome to
> me, per Ralf's mail.  Not that I'm saying no, but let's discuss ...

It's used in multiple contexts in configure scripts.  Gnulib has several
macros that assume tr availability.

As for concerns about portability issues, all of the issues listed in the
common tools have portability issues.  I don't see any reason to single
out tr as different from the rest, but wouldn't mind seeing a disclaimer
pointing to the autoconf manual on common tool portability issues.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9@...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkRCekACgkQ84KuGfSFAYCiMgCgmGFQfqso4symA2uqwVDA09cU
TnwAmgID/kk4F/PP85E26jl2nPYix0LC
=Twl1
-----END PGP SIGNATURE-----



Re: Add tr to common programs

by Karl Berry :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

    In other words, tr has been used in configure scripts long before this
    particular autoconf patch to config.status.  

Yes, I gathered that.  What I was confused about was your message
referred to using \r, but the Texinfo config.status was using $as_nl
(not $as_cr).  That made me think there were other uses of tr that the
Texinfo config.status was not exercising.  Which I guess is indeed the
case.

    Solaris /usr/ucb/tr

Well, Solaris /usr/ucb/anything has never been anything but trouble.

    that we already had problems trying either \015 or \r in awk.  

Ok.  I'm surprised.

    And literal ^M in the file was also problematic.

Of course.

    It's used in multiple contexts in configure scripts.  Gnulib has several
    macros that assume tr availability.
    ...
    I don't see any reason to single out tr

The only reason I was resisting was because your original msg implied
there was a single use of tr in configure.  If that were the case, it
seemed like it would be simpler to do something else.  But now it's
clear that's not the case.  So fine.  I'll ask rms about adding it.

    but wouldn't mind seeing a disclaimer pointing to the autoconf
    manual on common tool portability issues.

I believe it's already there.

Thanks,
Karl



Re: Add tr to common programs

by Karl Berry :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

    Subject: Add tr to common programs

rms approved, and it is now done.  (I'll update the gnulib copy
tomorrow unless someone else gets there first.)

karl