libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: solaris link line length problem == buggy sed


From: Olly Betts
Subject: Re: solaris link line length problem == buggy sed
Date: Wed, 18 Jul 2001 11:44:21 +0100
User-agent: Mutt/1.2.5i

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

I'm not sure this is what autoconf is meant to do (I wonder if ac_n should
be a literal newline rather than ac_c), but that's what the code actually
does if you fake the tests to fail.

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

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.

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

Cheers,
Olly



reply via email to

[Prev in Thread] Current Thread [Next in Thread]