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 it's like that in upcoming 4.2. > > For me, this doesn't make sense. The read may have been successful, but > the data is gone. It would make sense to return !=0 here, IMHO.
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 $?. > > I also quickly cross-read POSIX, since such weirdness usually comes from > there ;-) but I didn't see anything obvious. 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 mention read and getopts as being required to error out on a readonly variable (and given that ksh treats assignment different than unset on whether a non-interactive shell exits, the extent of the reaction for getopts and read will probably have to allow both behaviors). -- Eric Blake ebl...@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
