Re: [PATCH 2/2] config.status: minimize use of $tmp

[Eric Blake]

On 08/30/2010 11:38 AM, Ralf Wildenhues wrote:
> Hi Eric,
>
> * Eric Blake wrote on Mon, Aug 30, 2010 at 06:41:47PM CEST:
> > On 08/27/2010 01:24 PM, Eric Blake wrote:
> > > -  tmp=
> > > +  tmp= ac_tmp=
> > >     trap 'exit_status=$?
> > > -  { test -z "$tmp" || test ! -d "$tmp" || rm -fr "$tmp"; }&&   exit 
> > > $exit_status
> > > +  { test ! -d "${ac_tmp:=$tmp}" || rm -fr "$ac_tmp"; }&&   exit $exit_status
> >
> > And then I promptly used it incorrectly.  Per what we just
> > documented, we cannot assume that ${a=b} takes effect in the parent
> > shell if we are executing a child command like test
>
> I don't follow this.  Surely that Posix reference hints at
> http://austingroupbugs.net/view.php?id=255
> and is meant for assignments *before* commands only, as in for example
>    ac_tmp=$tmp test ! -d "$ac_tmp"
>
> but not the code above.
>
> Can you help me understand?

I think the intent of bug 255 was to make the point that there are two 
reasonable implementations for 'cmd ${a=b}' given the rules for simple 
shell commands:
http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_01

1. assign a, fork, exec cmd
2. fork, assign a, exec cmd

But I agree that the proposed wording in POSIX bug 255 only talks about 
side effects from step 4 (expansions encountered in the variable 
assignments preceding the command name) and not in step 2 (expansions 
encountered while determining the command name and arguments).  I'll ask 
for clarification from the Austin Group.

At any rate, it can't hurt to be safe by avoiding the issue, even if we 
don't (yet) have a counter-example or POSIX clarification on whether 
step 2 must always affect the parent environment.

--
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org