autoconf-patches
[Top][All Lists]
Advanced

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

Re: fix AT_SETUP's sh-escaping


From: Ralf Wildenhues
Subject: Re: fix AT_SETUP's sh-escaping
Date: Fri, 17 Nov 2006 08:49:08 +0100
User-agent: Mutt/1.5.13 (2006-11-01)

Hello Paul,

* Paul Eggert wrote on Wed, Nov 15, 2006 at 01:40:23AM CET:
> In <http://lists.gnu.org/archive/html/autoconf-patches/2006-11/msg00008.html>
> Ralf Wildenhues <address@hidden> writes:
> 
> > At which point I gave up.  I think using cat and here-documents
> > everywhere is a complete waste.
> 
> I agree.  How about something like the following patch instead?  It
> fixes most of the 'echo' problems I noticed.

Thanks for working on this.  Sorry to say, but I have some doubts:
- some Solaris expr have a serious length limitation (see
  autoconf.texi); even if it's not likely to be early in $PATH, it
  should probably not be used unconditionally.
- Libtool checks printf with long strings because some (presumably older
  Solaris?  I haven't tested at all) have problems with long arguments
  as well,
- Some uses now forbid to use both " and ' in arguments.  I dunno, but
    ERL='erl -Dfoo="quoted"'
  at least seems imaginable to me.  With $ac_[]_AC_LANG_ABBREV[]_v_output
  this looks like a no-go to me, even more so the line
      AS_ECHO(["$ac_var='\''$ac_val'\''"])
- some use cases may cause expr to match a user-passed empty string,
  resulting in 0 on output (that is at least how I interpret the
  statement about QNX 4.25 native expr).
- \n is not interpreted correctly by Solaris 8 /usr/ucb/tr,
- this patches touches a lot of internal code, lots of which is used in
  many places.  It would need thorough testing.

Esp. wrt. the last point (I'm thinking back of the _AC_DO* changes close
before 2.60, and the hassle that caused because of underquotation in
users' configure.ac), I wonder whether it would be a good idea to
postpone this patch to after 2.61, and just comment out the 'Macro with
backslash in a test title' test for now (as it neither fails nor passes
reliably).  After all, this isn't a regression.

> I'm not quite sure what the original problem was, though -- is there a
> simple test case for it?

Something like
  AT_SETUP([testing regex \(\t\)\1\])

The current title tests do not expose all failures reliably yet.  I have
some half-baked fix for that but it may be at least some days until I
can finish that.  (The test uses echo for the comparison string so it
won't catch the fact that \t has been expanded to TAB, and it does not
use --keyword.)

Cheers,
Ralf




reply via email to

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