[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: non portable sed scripts
From: |
Stepan Kasal |
Subject: |
Re: non portable sed scripts |
Date: |
Mon, 22 May 2006 18:39:49 +0200 |
User-agent: |
Mutt/1.4.2.1i |
Hello,
On Mon, May 22, 2006 at 06:16:07PM +0200, Ralf Wildenhues wrote:
> * Stepan Kasal wrote on Mon, May 22, 2006 at 02:30:44PM CEST:
> > 1) AC_PROG_SED patch (autoconf-20060522-prog-sed.patch)
...
> > Anyway, I agree it is better to change the macro now, before it is
> > first published.
>
> Yep.
OK, I installed that patch. The other two remain open.
> > Moreover, Solaris @command{/usr/xpg4/bin/sed} dumps core with long
> > scripts.''
>
> Maybe we should remove that altogether: [...]
Sounds fair, let's remove that sentence.
> [...] 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.)
(I meant to comment on this change but then forgot.)
Actually, the portability section contains some of that:
| Some traditional @command{grep} implementations do not work on long
| input lines. Also, many implementations do not support multiple regexps
| with @option{-e}: they either reject @option{-e} entirely (e.g., Solaris)
| or honor only the last pattern (e.g., @acronym{IRIX} 6.5).
- it doesn't mention AIX as the representation of the old tradition;
but we don't know any version number, shall we add "(e.g., AIX)"?
- it mentiones that Solaris doesn't understand -e
- it mentiones that sometimes only one -e option is handled, but it doesn't
mention NeXT; is NeXT still in use?
That's why the result of merging in the information you quoted
actually resulted in no change. Feel free to do it differently...
> FWIW, I'm fine with the rest of the doc changes.
... and commit. :-)
> > 3) autoconf-20060522-sed-safe.patch
...
> > - we could have ac_max_sed_lines=38, as in Autoconf 2.59
> > - [...] 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.
...
> 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.
OK, let's wait for him.
Have a nice day,
Stepan
- Re: non portable sed scripts, Paul Eggert, 2006/05/19
- Re: non portable sed scripts, Ralf Wildenhues, 2006/05/20
- Re: non portable sed scripts, Paul Eggert, 2006/05/21
- Re: non portable sed scripts, Ralf Wildenhues, 2006/05/21
- Re: non portable sed scripts, Ralf Wildenhues, 2006/05/22
- Re: non portable sed scripts, Paul Eggert, 2006/05/22
- Re: non portable sed scripts, Stepan Kasal, 2006/05/22
- Re: non portable sed scripts, Ralf Wildenhues, 2006/05/22
- Re: non portable sed scripts, Stepan Kasal, 2006/05/22
- Re: non portable sed scripts, Ralf Wildenhues, 2006/05/22
- Re: non portable sed scripts,
Stepan Kasal <=
- Re: non portable sed scripts, Paul Eggert, 2006/05/22
- Re: non portable sed scripts, Paul Eggert, 2006/05/23
- Re: non portable sed scripts, Tim Rice, 2006/05/23
- Re: non portable sed scripts, Stepan Kasal, 2006/05/23
- Re: non portable sed scripts, Ralf Wildenhues, 2006/05/23
- Re: non portable sed scripts, Tim Rice, 2006/05/23