Setting TMOUT in an optimized-away subshell removes the variable's special meaning

[sckendall2]

In a terminal, assuming ksh is the shell under test, run these commands:

ksh -c 'TMOUT=1; read v; print $?'
ksh -c '( TMOUT=0 ); TMOUT=1; read v; print $?'

The first command prints 1 because read times out after a second and yields status 1. So far so good. This is the documented behavior of read.

The second command should do the same. Instead, it hangs. That's the bug.

ksh93 has always had this bug. I've reproduced it in "Version M 93t+ 2009-05-01" in AIX 7.2; and in "Version AJM 93u+m/1.0.6 2023-06-13", RPM package ksh-1.0.6-3.el9.x86_64, on RHEL 9.3.

Apparently, ksh has optimized away the subshell process incorrectly, removing TMOUT's special meaning. You can see this by adding a command that blocks the optimization. E.g., the following correctly times out and prints 1:

ksh -c '( ulimit $(ulimit); TMOUT=0 ); TMOUT=1; read v; print $?'

FWIW, I suspected that all the variables named in this sentence (from the man page) would behave like TMOUT if set in an optimized-away subshell:

Unsetting LINENO, MAILCHECK, OPTARG, OPTIND, RANDOM, SECONDS, TMOUT, and _ removes their special meaning even if they are subsequently assigned to.

I tried with SECONDS and _. But, FWIW, I had no success. At least unset SECONDS has the documented effect, but even unset _ did not remove that variable's special meaning.

So, we have a bonus super-minor documentation bug: _ should be removed from that sentence in the man page.