Kevin F. Quinn wrote: > On Sat, 24 Mar 2007 14:23:39 -0400 > Chet Ramey <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] http://cnswww.cns.cwru.edu/~chet/ _______________________________________________ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash