Re: solaris link line length problem == buggy sed

[libtool]

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
> 
> This code seems to be taken from what autoconf puts into configure scripts.
> I believe it won't work as intended here in the case where neither -n nor
> \c is available, since the ac_[nct] values in autoconf are chosen for
> presentation reasons - if it can't say:
> 
> checking for foo... found
> checking for bar... found
> 
> It will say:
> 
> checking for foo...
> 
>         found
> checking for bar...
> 
>         found

The script isn't meant to be used "as-is". If you take the meat and
incorporate it into an autoconf macro, you'll be ok. Just get rid of
the above and use AC_MSG_CHECKING ... AC_MSG_RESULT.

> Reading the rest of Albert's scirpt it seems that in this case it'll just
> accept the first sed it tries (provided it handles lines of 10 characters).

It will try all sed's in the 'for _sed' command-line. I don't think

> 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?

> 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. 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 ...

-- 
albert chin (address@hidden)