[Top][All Lists]

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

Re: 2.62 AT_SETUP limitations

From: Joel E. Denny
Subject: Re: 2.62 AT_SETUP limitations
Date: Tue, 22 Apr 2008 20:14:26 -0400 (EDT)

On Tue, 22 Apr 2008, Eric Blake wrote:

> | Instead of adding the precondition "no unbalanced parentheses" to
> | AT_SETUP, why not add the precondition "the argument must expand properly
> | quoted"?
> Because AT_SETUP now uses the newly documented m4_expand macro, which in
> turn REQUIRES balanced () because it temporarily uses
> m4_changequote([(],[)]) to force preservation of unquoted space after
> comma.

With the assumption that the user has met the precondition of proper 
quoting, why is m4_expand needed in AT_SETUP?

> | AT_SETUP can use m4_dquote($1) to initially expand the argument.  If $1
> | meets the precondition, this will expand to a perfectly quoted string that
> | can be passed to, for example, m4_bpatsubst for shell-escaping.  The
> | result of m4_bpatsubst can be placed in the output shell script.
> m4_bpatsubst is dirt slow compared to m4_expand;

I was not talking about replacing m4_expand with m4_bpatsubst.  AT_SETUP 
uses AS_ESCAPE, which already uses m4_bpatsubst.  I was trying to show an 
example of how AT_SETUP could accomplish one of its tasks (shell-escaping, 
currently via AS_ESCAPE) given the precondition of proper quoting.

> Really, the problem is
> that there is no way to determine whether $1 is safe to expand

My precondition assumes it is.

> , short of
> expanding $1; thus, if it was not safe, you've already screwed up the
> state of the m4 parsing.  So we chose to document this as a limitation of
> AT_SETUP strings instead.

That's my suggestion as well... except the limitation is that the argument 
must expand properly quoted.  In the context of M4, this limitation seems 
more intuitive to me than parentheses balancing.

Thanks for your responses.

reply via email to

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