Red Hat Bugzilla – Bug 1268178
SH_LEVEL declared integer but treated as string for interactive shells in ksh93u+
Last modified: 2016-08-12 14:42:25 EDT
Description of problem:
We have the following piece of code in our interactive shell environment initialization:
# Provide protection for aggressive job control users
if (( SH_LEVEL <= 0 )); then
alias suspend='echo "This is a login shell."'
This breaks with ksh 93u+ as shipped by Redhat in RHEL6 since RHEL6.5 (ksh-20120801-10.el6.x86_64.rpm) - SH_LEVEL appears to be treated as a string (the integer declare notwithstanding) and the resulting environment contains:
$ echo $SH_LEVEL
The previous versions up to, ksh-20100621-19.el6.x86_64.rpm, do the arithmetics with undef==0 and make SH_LEVEL=1 (for a toplevel interactive).
Where are you experiencing the behavior? What environment?
SH_LEVEL should be treated as integer / numerical value, and should not be set to the string "SH_LEVEL+1" by the above environment initialization code when using the ksh-20120801* (ksh 93u+) versions of the package.
The ksh-20100621* versions correctly set SH_LEVEL to a numerical value while the ksh-20120801* versions set it to the string "SH_LEVEL+1".
It appears that the regression got introduced between ksh93u and ksh93u+; Oracle ships 93u, in Solaris,
version sh (AT&T Research) 93u 2011-02-08
and that is unaffected by the issue, while we have an internal build of ksh that matches the "new" one from RHEL6.5 and above,
version sh (AT&T Research) 93u+ 2012-08-01
that show the same behaviour change.
The "COMPATIBILITIES" file in usr/share/doc/ksh isn't mentioning anything, and nothing in the changelog is obvious
Version-Release number of selected component (if applicable):
Reproducible with any of:
It appears that "exporting variable assignments" are treated differently in ksh93u+ and ksh93t+. Something like:
integer MYFOO; export MYFOO=HOME+1234; echo $MYFOO; unset MYFOO
gives an "arithmetic error" message (and no variable assignment made to MYFOO) from the older ksh93t+ showing that the expression 'HOME+1234' is evaluated, while this happily assigns the string "HOME+1234" to MYFOO on ksh93u+.
If you change it to:
integer MYFOO; MYFOO=HOME+1234; export MYFOO; echo $MYFOO; unset MYFOO
the result is the same on both ksh93u+ and ksh93t+, in my case:
...ksh: /v/global/user/h/ho/hofmann: arithmetic syntax error
I.e. in short, the behavior of:
on ksh93t+ is the same as that of:
MYFOO=<whatever>; export MYFOO
i.e ksh93t+ evaluates the expression <whatever> before assigning the value to the variable, while on ksh93u+, it only does string substitution but not evaluation, like export MYFOO="<whatever>"
This is a very significant behaviour difference.
We've got a number of shell scripts that use SH_LEVEL for recursion detection and they break on upgrade to the default ksh in RHEL6.5 and later.
This is intentional behaviour as it was explicitely changed by upstream:
12-04-27 A bug in which old attributes were not cleared when assigning a
value using typeset has been fixed.
btw, "export" is an alias for "typeset -x"
The customer case reporting this problem was closed some time ago, and Comment #1 makes clear this was intentional design. As such, I am closing this case out. If there is a customer with ongoing concerns about this behavior, feel free to reopen this bug with details for further consideration.