Re: non portable sed scripts

[Ralf Wildenhues]

[ Cc:ing bug-autoconf again ]

* Tim Rice wrote on Tue, May 23, 2006 at 04:13:34AM CEST:
> On Mon, 22 May 2006, Ralf Wildenhues wrote:
> 
> > > Next I tried
> > >   CONFIG_SHELL=/bin/sh /bin/sh          \
> > >   /opt/src/gnu/coreutils-5.95/configure \
> > >   CONFIG_SHELL=/bin/sh
> > > Again a valid config.h and no error.
> > > That was all on my UnixWare 7.1.1 box.
> > 
> > Pleas try again with /usr/bin/posix/sh as shell; that's what the shell
> > selection algorithm of 2.59c will select.
> 
> Yes that fails. /usr/bin/posix/sh is a symbolic link to /u95/bin/sh which
> is hard linked to /u95/bin/ksh. /usr/bin/ksh is a symbolic link to
> /u95/bin/ksh.
> 
> Testing with /usr/bin/ksh fails too.
> I've attached a snip of the output of a "/usr/bin/posix/sh -x" test.

Thanks.  This snippet shows that it's the shell which actually generates
a broken script:

| + cat
| + 1> ./conf24563-17529/defines.sed 0<<
[...]
| s,^\([         ]*#[    ]*\)[^  ]*\([   ][      ]*HAVE_DECL_NANOSLEEP\)[       
 (].*$,\1define\2 0 ,
| s,^\([         ]*#[    ]*\)[^  ]*\([   ][      ]*HAVE_DECL_REALLOC\)[  
(].*$,\1define\2 1 ,
| s,^\([         ]*#[    ]*\)[^  ]*\([   ][      ]*HAVE_DECL_STPCPY\)[   
(].*$,\1define\2 0 ,
| HAVE_DECL_STRNDUP\)[   (].*$,\1define\2 0 ,
| s,^\([         ]*#[    ]*\)[^  ]*\([   ][      ]*HAVE_DECL_STRNLEN\)[  
(].*$,\1define\2 0 ,
[...]

So I assume we have an incarnation of a bug similar to this one
(quoting `info Autoconf "Here-Documents"'):

|    Many older shells (including the Bourne shell) implement
| here-documents inefficiently.  And some shells mishandle large
| here-documents: for example, Solaris `dtksh', which is derived from
| Korn shell version M-12/28/93d, mishandles variable expansion that
| occurs on 1024-byte buffer boundaries within a here-document.  Users
| can generally fix these problems by using a faster or more reliable
| shell, e.g., by using the command `CONFIG_SHELL=/bin/bash /bin/bash
| ./configure' rather than plain `./configure'.

Hmm.  This may actually present a regression on this system: the 2.59
shell selection algorithm would probably(?) have selected /bin/sh as
shell, whereas, due to changes we did because of OSF, /usr/bin/posix/sh
is preferred now.

I hope we get away with this.  The reduction of ac_max_sed_lines Paul
just installed may just save us, hopefully.  Otherwise, I don't see much
choice other than to suggest passing a more reliable shell.

Cheers,
Ralf