[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: read builtin and readonly variables
|
From: |
Eric Blake |
|
Subject: |
Re: read builtin and readonly variables |
|
Date: |
Tue, 04 Jan 2011 08:35:33 -0700 |
|
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.7 |
[adding David Korn for a ksh bug]
On 01/04/2011 08:25 AM, Chet Ramey wrote:
>> getopts also suffers from a difference in behavior between shells on
>> readonly arguments:
>>
>> $ ksh -c 'readonly foo; getopts a: foo -a blah; echo $?'
>> ksh[1]: ksh: foo: is read only
>> $ echo $?
>> 2
>> $ bash -c 'readonly foo; getopts a: foo -a blah; echo $?'
>> bash: foo: readonly variable
>> 1
>>
>> where non-interactive ksh completely exited on an invalid assignment,
>> but bash merely set $?.
>
> The shell should not exit on an assignment error with getopts, since
> getopts is not a special builtin.
Good point - 'unset' is different than 'getopts' or 'read' when it comes
to special builtin status, and I agree that only special builtins are
allowed to exit a non-interactive shell on an assignment error (POSIX
XBD 2.8.1 Consequences of Shell Errors). Even worse, neither ksh nor
bash exit the shell on 'readonly foo; unset foo; echo $?', so ksh's
behavior on 'getopts' seems like a ksh bug.
--
Eric Blake eblake@redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature