[Top][All Lists]

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

Re: non portable sed scripts

From: Stepan Kasal
Subject: Re: non portable sed scripts
Date: Mon, 22 May 2006 10:59:06 +0200
User-agent: Mutt/


> Ralf Wildenhues <address@hidden> writes:
> > So IMHO I wouldn't mind if only the bugfix and documentation parts of
> > the patch below were committed.

Ralf, I'm not sure what you mean by ``the bugfix'' but I guess it
might be this:
        (_AC_FEATURE_CHECK_LENGTH): Do not remove `conftest.*', but only
        the files that this macro actually generates, to keep the file
and I agree that it is harmless and should be committed.
(BTW, I do not see the change in your patch.)

I share your opinion that committing all the AC_PROG_SED & Co. would
be dangerous and would require a lot of testing.

I think we should lower ac_max_sed_lines artificially to workaround the
problem which started this thread.

I'm attaching a patch, which uses the value of 60, which usually leads to
sed scripts of size < 5000.  This should be reasonably safe.
Or should we go to the old value of 38?

Since most packages use only one config header, we don't have to be
sad that its creation has been slowed down.

What do you think about this hack?

On Sun, May 21, 2006 at 10:51:01PM -0700, Paul Eggert wrote:
> Switching to awk sounds like a win to me, [...]. [...] but nowadays
> we can assume an almost-POSIX-complaint awk, if we run AC_PROG_AWK.

I also would like to use awk in config.status.
But I think that AC_PROG_AWK shouldn't be used directly here:
- AC_PROG_AWK looks for an implementation which is as POSIX-compliant
  as possible
- the ``config awk'' can be any reasonable awk, ie. we only have to
  avoid Solaris' /bin/awk

I was told that there are concerns that the /usr/xpg4/bin
implementations are less debugged and less eagerly fixed then the
/bin ones.  Perhaps we should just check whether `awk' behaves sanely
and switch to `nawk' if it doesn't.

Have a nice day,

Attachment: autoconf-20060522-sed-safe.patch
Description: Text document

reply via email to

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