Re: solaris link line length problem == buggy sed

[Olly Betts]

On Wed, Jul 18, 2001 at 08:29:05AM -0500, address@hidden wrote:
> On Wed, Jul 18, 2001 at 11:44:21AM +0100, Olly Betts wrote:
> > On Tue, Jul 17, 2001 at 10:15:26PM -0500, address@hidden wrote:
> > > if (echo "testing\c"; echo 1,2,3) | grep c >/dev/null; then
> > >   if (echo -n testing; echo 1,2,3) | sed s/-n/xn/ | grep xn
> > > /dev/null; then
> > >     ac_n= ac_c='
> > > ' ac_t='        '
> > >   else
> > >     ac_n=-n ac_c= ac_t=
> > >   fi
> > > else
> > >   ac_n= ac_c='\c' ac_t=
> > > fi
[snip]
> > Not sure how to fix this portably.  My only idea so far is to echo a longer
> > string and truncate it with dd, but the GNU coding standard don't include dd
> > in the list of utilities which you are allowed to use in a configure script.
> > Perhaps we could use it if present, and just use the sed we're given if not.
> 
> What is wrong with the "portability" of the meat of my script?

What I explained (probably badly) in my original message.  I'll try again.

The problem is if echo understands neither "-n" or "\c".  In this case the
code above will set ac_n to empty and ac_c to a literal newline (ac_t will
be a literal tab, but is unused by the script).

This means that later on the script will put "0123456789" followed by 2
newlines (one from $ac_c and one from echo) into /tmp/$$-sed-in.  So rather
than building up an increasingly long line, it will build up a file with an
increasing number of lines, alternately "0123456789" and blank.  The lack of
long lines means that the tests will pass for any sed, so it'll use the
first one.

Is using tr OK (the GNU coding standards don't list it)?  If "tr -c" is
portable, then this file can be created using:

echo 012345678 | tr -c 012345678 99999999999 > /tmp/$$-sed-in

This avoid using escapes in tr (some may be portable but I just don't know).
The reason there are 11 nines is to cope in case tr uses system V semantics
and truncates set 1 to the length of set 2.  Then set 1 just contains a zero
byte and the newline isn't changed.

> > One other thought - this check prevents the knowledgable user from providing
> > a better sed by putting it earlier on his or her PATH.  Perhaps it ought to
> > check for sed without an explicit path first:
> > 
> > for _sed in sed /bin/sed /usr/xpg4/bin/sed
> 
> This is just a sample. It is not meant as *the* solution, just a
> starting point from which to achieve the solution.

Please don't take my comments as harsh criticism - I'm just trying to point
up niggles to help reach the best solution possible.  The script may not be
meant as the whole answer, but it seems wise to raise issues which might not
occur to whoever reworks it into libtool.

> Definitely, "sed"
> and "gsed" should be in the list of options below. Actually, I would
> AC_PATH_PROG(SED, sed) and use $SED in the list above. Ditto for gsed.
> The user could then override the value of SED with:
>   SED=<blah> ./configure ...

Yes, that seems a good approach.

Cheers,
Olly