Terrence J. Doyle
2014-12-23 23:30:05 UTC
One of the problems I brought up in
http://lists.research.att.com/pipermail/ast-users/2014q4/004686.html is
the dysfunctional job control in ksh from ast-open-2014-09-29. I decided
to try to track down this issue and fix it myself. I rebuilt
ast-open-2014-09-29 with "package make debug=1" so I could use gdb.
There was a new problem with this debug build, but I'll cover that in my
next message.
I set breakpoints at each of the places where jobs.jobcontrol
was set to zero. Then when one of these breakpoints triggered I did a
backtrace and found that job control was being turned off in
sh_subshell() which was called from comsubst() which was called from
copyto()... . As I examined these functions and the calling sequence, it
became evident that this is occurring because of a subshell invoked
through back ticks. I scratched my head for a moment and wondered why
the shell would invoke a subshell via back ticks when it starts. But, of
course it's from uses of back ticks in my .profile and .kshrc. What's
more, on Mac OS 10.5 the Apple-provided /etc/profile uses back ticks.
OK, so I found the trigger for this problem. But, why didn't this
happen with ksh-20120612? And, how do I fix it? To answer these
questions I compared subshell.c from the two versions of ksh. In
sh_subshell() from ksh-20140929 I found this assignment:
sp->jobcontrol = job.jobcontrol;
at line 604 of subshell.c in a new section of code. This assignment is
in the wrong place. It's mean't to save the value of jobs.jobcontrol so
that it can be restored later on. The problem is that jobs.jobcontrol is
set to zero 6 lines before. So, now when jobs.jobcontrol is restored,
it's incorrectly restored to zero. The right place to save
jobs.jobcontrol is before it's set to zero. But, that's already being
done at line 596 of subshell.c. So, the fix for this problem is to
simply remove the assignment at line 604. To that end I've attached
subshell.c.diff.
Oh, and at line 601 of subshell.c you see:
if(comsub==1)
That's why this problem occurs only when back ticks are used.
I think this is a rather high priority fix. Loosing job control just
because one's system's out-of-the-box /etc/profile contains back ticks
might be enough to drive many away from Korn Shell. I'm certainly glad I
got job control back.
Terrence Doyle
http://lists.research.att.com/pipermail/ast-users/2014q4/004686.html is
the dysfunctional job control in ksh from ast-open-2014-09-29. I decided
to try to track down this issue and fix it myself. I rebuilt
ast-open-2014-09-29 with "package make debug=1" so I could use gdb.
There was a new problem with this debug build, but I'll cover that in my
next message.
I set breakpoints at each of the places where jobs.jobcontrol
was set to zero. Then when one of these breakpoints triggered I did a
backtrace and found that job control was being turned off in
sh_subshell() which was called from comsubst() which was called from
copyto()... . As I examined these functions and the calling sequence, it
became evident that this is occurring because of a subshell invoked
through back ticks. I scratched my head for a moment and wondered why
the shell would invoke a subshell via back ticks when it starts. But, of
course it's from uses of back ticks in my .profile and .kshrc. What's
more, on Mac OS 10.5 the Apple-provided /etc/profile uses back ticks.
OK, so I found the trigger for this problem. But, why didn't this
happen with ksh-20120612? And, how do I fix it? To answer these
questions I compared subshell.c from the two versions of ksh. In
sh_subshell() from ksh-20140929 I found this assignment:
sp->jobcontrol = job.jobcontrol;
at line 604 of subshell.c in a new section of code. This assignment is
in the wrong place. It's mean't to save the value of jobs.jobcontrol so
that it can be restored later on. The problem is that jobs.jobcontrol is
set to zero 6 lines before. So, now when jobs.jobcontrol is restored,
it's incorrectly restored to zero. The right place to save
jobs.jobcontrol is before it's set to zero. But, that's already being
done at line 596 of subshell.c. So, the fix for this problem is to
simply remove the assignment at line 604. To that end I've attached
subshell.c.diff.
Oh, and at line 601 of subshell.c you see:
if(comsub==1)
That's why this problem occurs only when back ticks are used.
I think this is a rather high priority fix. Loosing job control just
because one's system's out-of-the-box /etc/profile contains back ticks
might be enough to drive many away from Korn Shell. I'm certainly glad I
got job control back.
Terrence Doyle