On Sat, 19 May 2007 12:22:04 +1000 Herbert Xu <[EMAIL PROTECTED]> wrote:
> On Sat, May 19, 2007 at 12:05:39AM +0200, Kevin F. Quinn wrote: > > > > This was discussed in some detail on the bash mailing list: > > > > http://www.mail-archive.com/bug-bash%40gnu.org/msg02622.html > > > > Notably ksh, and the Solaris xpg4 sh, which both claim Posix > > compliance, behave the way bash does with regards this issue. > > Well the Solaris xpg4 shell was ksh last time I checked :) > Also bash derives heavily from the Korn shell. So in the > past I have not taken their collective behaviour as a > litmus test for POSIX compliance. > > After all, POSIX isn't simply about the Korn shell. > > > Chet Ramey explains in that thread how he reaches the conclusion > > that the Posix (well SUS) specifies that behaviour (I won't > > paraphrase to avoid mis-representation) - in particular here: > > > > http://www.mail-archive.com/bug-bash%40gnu.org/msg02627.html > > I can see how this paragraph can be construed to have this meaning. > > 4. Each variable assignment shall be expanded for tilde > expansion, parameter expansion, command substitution, > arithmetic expansion, and quote removal prior to assigning > the value. > > However, it can also be read as simply saying that parameter expansion > must occur before the variables are assigned, and nothing more. See below - step 2 causes parameter expansion on the command to be performed before the variable assignments are expanded in step 4. > Normally if there is an intention to specify such a requirement and > it had to be done in an ambiguous way like this, there would be a > clarification in the rationale. In this case there isn't any. > > Of course we can't predict what a future revision might say, but > right now I do not agree that there is a requirement for this > behaviour, which I might add goes against all BSD-derived Bourne > shells whose behaviour were certainly given consideration in POSIX. > > > > $ bash -c 'x=${K:=dvb0.net0} A=${K#dvb} echo $A' > > > > > > $ > > > > > > As you can see, whether the first assignment affects a second > > > assignment is qutie haphazard within bash. > > > > With respect to the third example, SUS is quite clear, I think. > > http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_09_01 > > explicitly saves the 'variable assignments' until after 'expansion', > > where expansion is explicitly stated not to occur in variable > > assignments. > > Could you quote the specific passage that states this? That was my reading of 2.9.1 of IEEE Std 1003.1, 2004 Edition (see above for link): -------- 2.9.1 Simple Commands A "simple command" is a sequence of optional variable assignments and redirections, in any sequence, optionally followed by words and redirections, terminated by a control operator. When a given simple command is required to be executed (that is, when any conditional construct such as an AND-OR list or a case statement has not bypassed the simple command), the following expansions, assignments, and redirections shall all be performed from the beginning of the command text to the end: 1. The words that are recognized as variable assignments or redirections according to Shell Grammar Rules are saved for processing in steps 3 and 4. 2. The words that are not variable assignments or redirections shall be expanded. If any fields remain following their expansion, the first field shall be considered the command name and remaining fields are the arguments for the command. 3. Redirections shall be performed as described in Redirection. 4. Each variable assignment shall be expanded for tilde expansion, parameter expansion, command substitution, arithmetic expansion, and quote removal prior to assigning the value. In the preceding list, the order of steps 3 and 4 may be reversed for the processing of special built-in utilities; see Special Built-In Utilities. -------- Step 1 says that variable assignment words are saved for processing in steps 3 & 4, and step 2 performs expansion (including parameter expansion), excluding variable assignments. So in: x=${K:=dvb0.net0} A=${K#dvb} echo $A the $A is expanded (by step 2) before the two variable assignments are performed (by step 4), so the parameter to 'echo' has the value of A prior to the statement rather than the value of ${K#dvb}. This is the bash behaviour: $ bash -c 'x=${K:=dvb0.net0} A=${K#dvb} echo $A' $ bash -c 'x=${K:=dvb0.net0} A=${K#dvb} env | grep ^A=' A=0.net0 The other statement that I understood to be important with respect to the original issue, is the "expansions, assignments, and redirections shall all be performed from the beginning of the command text to the end". To me this means that if you have a series of assignments, later assignments should take account of previous assignments. > > What do the compliance tests show for dash in this area? I mention > > it as passing the compliance tests is worthwhile regardless how > > ambiguous the specification may be, and Chet mentioned it as an > > argument for the behaviour of bash. > > I couldn't find a test for this in VSC Lite. If you're aware a > relevant test, please let me know. I'll leave that for Chet to cover, as it was his point originally - maybe it's only in the full tests. I've added him to CC. -- Kevin F. Quinn
signature.asc
Description: PGP signature
