[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 ebl...@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature