On Fri, 18 May 2007 21:02:14 +1000 Herbert Xu <[EMAIL PROTECTED]> wrote:
> On Wed, May 09, 2007 at 01:22:33PM -0400, Doug Goldstein wrote: > > In short the issue is with variables used on the same lines.... > > > > example: > > > > unset A B; A="moo" B="$A more"; echo $A , $B > > Thanks for the report! > > This had previously been reported by Debian as well. I apologise > for the delay in responding to this. > > First of all I've looked at the POSIX specification and there is no > requirement for this behaviour. Neither is there a requirement for > the shell to behave in the way that dash does. 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. 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 > This means that both bash and dash are compliant in this respect. > > Now I have considered changing dash's behaviour to match that of > bash. However, in doing so I found that bash's behaviour is in > fact quite inconsistent with itself. For example, > > $ bash -c 'K=dvb0.net0 A=${K#dvb} eval echo \$A' > > $ bash -c 'a=/bin PATH=$a ls /dev/null' > bash: line 1: ls: No such file or directory > $ 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. $ bash -c 'K=dvb0.net0 A=${K#dvb} env | grep ^A=' A=0.net0 $ bash -c 'a=/bin PATH=$a env | grep ^PATH=' PATH=/bin so I don't understand why bash does what it does on the other two examples - I'll run them by Chet on the bash mailing list to see what he says. > On the other the behaviour of dash is self-consistent, the effect > of the assignment is not realised until after parameter expansions > have all completed. > > Therefore I've concluded that scripts cannot safely rely on this > behaviour and thus there is no clear benefit in changing dash's > behaviour at this time. 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. -- Kevin F. Quinn
signature.asc
Description: PGP signature
