[adding bug-bash] On 05/16/2011 07:23 PM, Wayne Pollock wrote: > (While cleaning up the standard for case statement, consider that it is > currently > unspecified what should happen if an error occurs during the expansion of the > patterns; as expansions may have side-effects, when an error occurs on one > expansion, should the following patterns be expanded anyway? Does it depend > on > the error? It seems reasonable to me that any errors should immediately > terminate > the case statement.)
Well, that's rather all over the place, but yes, it does seem like bash was the buggiest of the lot, compared to other shells. Interactively, I tested: readonly x=1 case 1 in $((x++)) ) echo hi1 ;; *) echo hi2; esac echo $x.$? bash 4.1 printed: bash: x: readonly variable hi1 1.0 which means it matched '1' to $((x++)) before reporting the failure assign to x, and the case statement succeeded. Changing the first "1" to any other string printed hi2 (the * case). zsh printed: zsh: read-only variable: x 1.0 which means it aborted the case statement before executing any clauses, but left $? at 0. ksh printed: ksh: x: is read only 1.1 which means that both the case statement was aborted, and $? was impacted. dash printed: dash: arithmetic expression: expecting primary: "x++" 1.2 so it was like ksh other than choice of error status. -- Eric Blake ebl...@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
