[Top][All Lists]
[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