bug-bash
[Top][All Lists]
Advanced

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

Re: variable assignments and parameter expansion in a single command


From: Chet Ramey
Subject: Re: variable assignments and parameter expansion in a single command
Date: Sat, 24 Mar 2007 19:32:35 -0400
User-agent: Thunderbird 1.5.0.10 (Macintosh/20070221)

Kevin F. Quinn wrote:
> On Sat, 24 Mar 2007 14:23:39 -0400
> Chet Ramey <chet.ramey@case.edu> wrote:
> 
>> Mike Frysinger wrote:
>>> i'm trying to determine whether POSIX allows for utilizing of
>>> variables in simple commands that were defined earlier in the same
>>> command ... in other words, whether this snippet:
>>> unset A B
>>> A="moo" B="$A more"
>>> echo $A , $B
>>> should display moo twice or just once:
>> As I read Posix, twice, as long as there are only assignment
>> statements in the command.  Assignment statements preceding simple
>> commands are treated differently.
> 
> I don't see that posix defines simple commands like that - an
> assignment _is_ a simple command:

You are correct.  I meant what posix calls a "command name" -- without
that, the assignment statements affect the current shell environment;
with a command name they do not.

> The same section (that Mike referred to -
> http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_09_01)
> also explicitly says that variable assignments are "saved for
> processing in steps 3 and 4".  Step 2 expands all words except variable
> assignments and redirections - my interpretation of "variable
> assignment" is the `A=' part of the statement; i.e. that the rhs of
> the assignment is expanded.

It's not; the entire word, including the portion after the `=', is a
variable assignment.

 Step 3 does the redirections and step 4
> does the variable assignments.  So if expansions are done before the
> assignments, any assignment referring to other variables that are
> assigned, should be expanded with the value before the assignment.
> 
> Either way, I've yet to find a shell that claims posix-compliance that
> does it the bash way; all of Solaris sh, BSD sh/ash/dash (not sure if
> Solaris is BSD or SYSV - or indeed if there's any difference) and
> busybox all yield "moo , more" in Mike's example.

None of these shells are or claim posix compliance.  The Solaris posix
shell is /usr/xpg4/bin/sh (or something).  Of the others, dash is closest
to Posix compliance.

In the past, both bash and ksh93 have passed compliance tests, though
bash-3.2 is currently not compliant in command substitution parsing.

> 
> Hmm:
> 
> $ A=one B="$A two" env
> A=one
> B= two
> ...
> $ A=one B="$A two" env | grep ^[AB]=
> A=one
> B=one two

I don't get these results with bash-3.2.  I get "one two" for B both times
with bash (and ksh93, incidentally).

> 
> $ cat show_ab
> #!/bin/bash
> echo A: $A
> echo B: $B
> $ A=one B="$A two" ./show_ab
> A: one
> B: two
> $ A=one B="$A two" ./show_ab | more
> A: one
> B: one two

Again, bash-3.2 and ksh93 yield "one two" for the value of B in both
cases.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                       Live Strong.  No day but today.
Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/




reply via email to

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