Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

zsh bug in . builtin



According to POSIX,

A syntax error in a special built-in utility may cause a shell executing
that utility to abort, while a syntax error in a regular built-in utility
shall not cause a shell executing that utility to abort. (See Consequences
of Shell Errors for the consequences of errors on interactive and
non-interactive shells.) If a special built-in utility encountering a
syntax error does not abort the shell, its exit value shall be non-zero.
http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_14

However, zsh fails to recognize syntax errors encountered when sourcing a
file (tested with zsh 4.3.9):

$ echo 'if' > tmp
$ zsh -c '. ./tmp; echo $?'
0
$ zsh -c 'emulate sh; . ./tmp; echo $?'
./tmp:2: parse error near `\n'
0
$ zsh -c 'emulate sh; (. ./tmp); echo $?'
./tmp:2: parse error near `\n'
0

For the first test, you can do whatever (since zsh is not in sh-mode, so
it doesn't have to follow POSIX rules).  For the second line, it would be
feasible if $? is not echoed (because the entire shell was aborted), but
it is not acceptable to print 0.  And for the third line, the echo $?
should always be reached (regardless of whether the subshell aborted or
exited with failure), but again it is not acceptable to print 0.

-- 
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9@xxxxxxx



Messages sorted by: Reverse Date, Date, Thread, Author