bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Shell case statements


From: Eric Blake
Subject: Re: Shell case statements
Date: Thu, 19 May 2011 16:09:52 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.10

[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   eblake@redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]