[Top][All Lists]

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

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

From: Eric Blake
Subject: Re: [PATCH 2/2] config.status: minimize use of $tmp
Date: Mon, 30 Aug 2010 11:55:24 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100806 Fedora/3.1.2-1.fc13 Mnenhy/0.8.3 Thunderbird/3.1.2

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 
+  { 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
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:

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

reply via email to

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