On 01/04/2011 08:05 AM, Eric Blake wrote:
> I couldn't find anything either - the POSIX wording for readonly only
> mentions assignment and unset as requiring errors. I think that's an
> unintentional hole in POSIX, though, so I'm going ahead and submitting a
> bug report to have readonly also men
On 1/4/11 10:35 AM, Eric Blake wrote:
>> 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
>
[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
On 1/4/11 10:05 AM, Eric Blake wrote:
> On 01/03/2011 11:41 PM, Jan Schampera wrote:
>> Hello list,
>>
>>
>> the read builtin command, when trying to assign to a readonly variable
>> after reading the data, spits an error message. This is fine.
>>
>> But the return status is 0. It "always" (down to
On 01/03/2011 11:41 PM, Jan Schampera wrote:
> Hello list,
>
>
> the read builtin command, when trying to assign to a readonly variable
> after reading the data, spits an error message. This is fine.
>
> But the return status is 0. It "always" (down to 2.04 was tested) has
> been like that, and
On Tue, Jan 4, 2011 at 12:41 AM, Jan Schampera wrote:
> Hello list,
>
>
> the read builtin command, when trying to assign to a readonly variable after
> reading the data, spits an error message. This is fine.
>
> But the return status is 0. It "always" (down to 2.04 was tested) has been
> like tha
