Re: non portable sed scripts

[Stepan Kasal]

Hello,

On Tue, May 23, 2006 at 10:43:22AM +0200, Ralf Wildenhues wrote:
> | 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'.

you are so bright, Ralf!

> [...]  Otherwise, I don't see much
> choice other than to suggest passing a more reliable shell.

Of course there is a general solution: we can actively test the shell
for this problem, in the ``detect better shell'' routine.
But this will enlarge the generated script by a kilobyte :-O

Have a nice day,
        Stepan