Re: non portable sed scripts

[Ralf Wildenhues]

Hi Stepan,

* Stepan Kasal wrote on Mon, May 22, 2006 at 02:30:44PM CEST:
> 
> I felt that things are getting more compliacted than necessary, so I
> broke this into 6 patches.

Thanks for doing this!

> 1) AC_PROG_SED patch (autoconf-20060522-prog-sed.patch)

> Well, I don't agree that this is a ``bugfix''.

Granted.  That probably stretched it too much.

> The macro searches for a ``good sed'' and you strengthened the
> conditions for that.  In particular, the macro will now fail on
> Solaris systems without xpg4, right?

No.  It will work with /bin/sed and /usr/xpg4/bin/sed.  It will reject
/usr/ucb/sed.  I've tested that on Solaris 2.6; furthermore, I tested
AIX 4.3.3, HP-UX 10.20, IRIX 6.5, Tru64 4.0D (by running the "Torturing
config.status" test), each without GNU sed.  Also note that the macro
does allow to override the choice by the user.

> The previous version found an implementation which
> worked with small scripts.

Yes, the previous version only checked long input lines.

> Anyway, I agree it is better to change the macro now, before it is
> first published.

Yep.

> 2) The doc fixes.
> 
> I modified the following text:
> > +Solaris @command{/usr/ucb/sed} has a limit of about 6000 bytes for the
> > +internal representation of the sed script, which can not be circumvented
> > +using more than one script file.  It fails with longer scripts, and
> > +and Solaris @command{/usr/xpg4/bin/sed} dumps core with long scripts.
> 
> The first half of the second sentence still speaks about
> /usr/ucb/sed, while the second half speaks about another one; yet
> they are connected by a comma.  I think this is unfortunate, so I
> changed it this way:
> ``[...] more than one script file, and it fails with longer scripts.
> Moreover, Solaris @command{/usr/xpg4/bin/sed} dumps core with long
> scripts.''

Maybe we should remove that altogether: I haven't been able to analyze
this failure sufficiently to state good circumstances in which it
happens (and I don't like to propagate possibly incorrect information).

> I also shortened the description of AC_PROG_SED and AC_PROG_*GREP:
> - We shall not mention that we prefer GNU sed; that may change if we
>   find a serious bug in certain version of it.
> - We shall not mention that we look for the binaries ``on PATH'';
>   this is not true for AC_PROG_GREP and can change for other macros,
>   too.

OK.  But you removed mention of bugs of specific grep implementations:

| -On AIX the default @code{grep} silently truncates long lines on the
| -input before matching.  On Solaris, @code{/usr/bin/grep} does not
| -understand the @option{-e} option.  On NeXT, @code{grep} understands only a
| -single @option{-e} option.

These aren't listed elsewhere, and this information is very valuable,
if only to know which systems to test for any change of those macros.
(But it should probably move to the shell portability section.)

FWIW, I'm fine with the rest of the doc changes.

> 3) autoconf-20060522-sed-safe.patch

> Of course, this is not a general solution, just a hack which fixes
> most real world cases.  The proposed variant is relatively weak, and
> a stronger variants can be imagined:
> - we could have ac_max_sed_lines=38, as in Autoconf 2.59
> - we could shorten the scripts for config files (Dan Manthey's code)
>   by lowering _AC_SED_CMD_LIMIT, too.  To make the fragments' size simiar
>   to what we had with 2.59, we could set it to say 45.  (The previous
>   version had 2 commands per each substitution, that is about 50, and
>   then subtract another 5 to compensate for all those |#_!!_#|.)

I'm undecided about this.  Paul has more experience and
will have to deal with bug reports against coreutils,  ;-)
so I'd appreciate input on this.

Cheers,
Ralf