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: Joel E. Denny
Subject: Re: fix AT_SETUP's sh-escaping
Date: Thu, 26 Oct 2006 23:02:40 -0400 (EDT)

On Thu, 26 Oct 2006, Eric Blake wrote:

> According to Joel E. Denny on 10/26/2006 12:28 PM:
> > 
> > Ok, this seemingly obvious point didn't click with me completely 
> > yesterday.  It seems a little funny to me that anyone would (1) pass in a 
> > test description with macros to be expanded later and then (2) expect that 
> > nothing strange would happen if the expansions contained characters that 
> > are special to whatever the output language happens to be.
> 
> Until you realize that having macros expanding to characters that are
> special in M4 is a desirable feature in autom4te, and that expanding the
> macros early can mess up M4 parsing, whereas expanding them late will
> work.  The manual documents the problems of having a macro that expands to
> "#include <stdio.h>", and expanding that early, where it is treated as an
> M4 comment, vs. expanding it late for a valid C code snippet.

In your example, the user wants the special characters of the output 
language (C) to remain unescaped in order to let them do whatever they do 
in the output language.  That's what I'm saying the user would naturally 
expect, so I believe my initial point (quoted above) is the same as yours.

In the case of AT_SETUP, Stepan is suggesting that we escape the special 
characters of the output language (Bourne shell) so that they won't have 
special meaning there.  Following the philosophy of your example, the user 
should instead expect them to have special meaning, and so Stepan's 
suggestion would be wrong.  However, I agree with Stepan that this 
philosophy would only cause trouble since I believe AT_SETUP reserves the 
right to use the expanded text in many contexts with the Bourne shell 
output: in double-quotes, in a comment, in single-quotes, in a here 
document, etc.

On the other hand, implementing Stepan's suggestion is beyond me for now, 
so my latest patch follows yours instead.




reply via email to

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