[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bug batch
Re: bug batch
Thu, 13 Jun 2013 05:24:28 -0500
KMail/4.10.4 (Linux/3.9.4-pf+; KDE/4.10.4; x86_64; ; )
On Thursday, June 13, 2013 02:54:57 AM Linda Walsh wrote:
> I can't speak to all your cases, but I had comments on a few:
> Dan Douglas wrote:
> > Most shells (and GCC) consider not grouping the assignment in a situation
> > like this an error. Bash tolerates it, apparently reversing associativity:
> > : $((1 == x = 1)) # Error in dash/ksh/mksh/zsh/etc
> ---- If you do it without the ':', it returns a false status. The colon
> doesn't seems to return true or false based on whether or not there was a
> syntactic error, but not for a command that runs normally and returns any
The colon and status aren't relevant to this test. It's an illegal arithmetic
expression because the comparison should be evaluated before the assignment,
throwing a fatal shell error because the assignment lacks an identifier on the
LHS. It might not cause any ambiguity the way Bash is currently doing it, it
just won't warn of the ensuing portability problem.
> > 2. += environment assignments
> > 2a. POSIX mode += w/ special builtin.
> You say you got an answer of '2'? When I did your test interactively, it
> came out '25' in non-posix mode. (bash V 4.2.45). I have a feeling that you
> asked for posix (dysfunctional) and got it. I don't recall the posix
> standard specifying "+=" as an operator, but I'm FAR from an expert on posix.
+= isn't POSIX. You won't get the same results in non-POSIX mode because the
eval won't leak its environment. I don't expect POSIX mode to affect the
behavior of +=, but it provides extra information that isn't apparent in
non-POSIX mode in this case.
The main thing being demonstrated here is the difference from 4.2 - 4.3 and the
fact that it isn't appending to the previous value. Bash in POSIX mode should
be closer to the other shells being compared.
> .... Anyway, don't have time to analyze the rest, but those above looked
> like bash is doing the right thing...?
It doesn't apply modified behavior for the -i attribute. AFAICT, that isn't
documented and is possibly unintentional.