The ksh mode of zsh emits errors when it should not during a syntax only check, ie from the manual: -n Read commands and check them for syntax errors, but do not execute them. Ignored for interactive shells. # ksh --version <------------------- RHEL version zsh 4.2.6 (i686-redhat-linux-gnu) Also impacts latest upstream version: [root@faraday zsh]# ./ksh --version zsh 4.3.9 (x86_64-unknown-linux-gnu) Easily reproduced using the following abbreviated test case, note the missing variable initialisation: [root@faraday zsh]# more t.ksh if [[ $(($v % 2)) == 1 ]]; then a=ok else a=nok fi Results: ### real ksh, syntax checking only, no problem (correct) [root@faraday zsh]# ksh -n ./t.ksh ### zsh, syntax checking only, problem (incorrect, bug) [root@faraday zsh]# ./ksh -n ./t.ksh ./t.ksh:1: bad math expression: operand expected at `% 2' ### real ksh, complains at runtime (correct) [root@faraday zsh]# ksh ./t.ksh ./t.ksh: line 1: % 2: arithmetic syntax error ### zsh, also complains at runtime (correct) [root@faraday zsh]# ./ksh ./t.ksh ./t.ksh:1: bad math expression: operand expected at `% 2' This means that the second case (zsh -n flag) would appear to be in error, since syntactically speaking, the script is ok. The shell would _ONLY_ know about the problem at runtime when the variable is checked/expanded. In other words, the zsh should not complain about the script when -n flag is used (syntax check only), however it is _right_ to complain about the script at runtime. This defect results in development compatibility issues across a heterogenous environment using ksh scripts.
I forgot to add, the './ksh' is just linked to zsh in the above test cases.
You will also find it doesn't like this in the ksh compatibility mode of the zsh when using the -n option: [[ -z ${XXX} ]] && exit 1 Although it is perfectly good syntax, the -n syntax checking option doesn't like it. A return code of 1 is returned from the script in which this code segment resides but there was no output to tell us what was wrong. We found this by trial and error, stripping the code down bit by bit.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2010-0804.html