Re: Bug related to stdin/always/jobcontrol

[Peter Stephenson <p.stephenson@samsung.com>]

On Fri, 2 Sep 2016 20:39:39 +0200
Christian Neukirchen <chneukirchen@gmail.com> wrote:
> Stripped down test case for a mysterious loss of child:
> 
> zsh 5.2 (x86_64-unknown-linux-gnu)
> zsh-5.2-0-gc86c20a
> VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Aug 29 2016 13:06:04)
> Included patches: 1-2207
> 
> zsh -f
> juno% v() { { vim - } always { true } }
> juno% ls | v
> ^Z
> zsh: running    v
> juno% fg
> fg: no current job

It looks like the job state is quite seriously challenged.

I think the relevance of the always and stdin is probably that there's
something for the job to fix up after it finishes, so the vim process
can't be fully detached from the subshell it's in.

When fg is run, the state of the job you can see has flags 0x2012:

#define STAT_STOPPED	(0x0002) /* all procs stopped or exited          */
#define STAT_LOCKED	(0x0010) /* shell is finished creating this job, */
                                 /*   may be deleted from job table      */
#define STAT_SUBLEADER  (0x2000) /* is super-job, but leader is sub-shell */

This doesn't have STAT_INUSE, so it's not clear "jobs" should be
reporting it at all.  Adding STAT_INUSE and fg'ing doesn't help; it does
attempt to bring the command to the foreground but then gets stuck and
stays stuck even if the vim command is killed from elsewhere.

pws      27402 25329  7 16:28 pts/1    00:00:01 ./zsh
pws      27423 27402  0 16:29 pts/1    00:00:00 vim -
pws      27425 27402  0 16:29 pts/1    00:00:00 ./zsh

That first ./zsh is the parent shell; I guess 27425 is the subshell
process.

job 3 in the job table appears to be valid and is in use but is marked
as STAT_NOPRINT.  It has status 0x173:

#define STAT_CHANGED	(0x0001) /* status changed and not reported      */
#define STAT_STOPPED	(0x0002) /* all procs stopped or exited          */
#define STAT_LOCKED	(0x0010) /* shell is finished creating this job, */
                                 /*   may be deleted from job table      */
#define STAT_NOPRINT	(0x0020) /* job was killed internally,           */
                                 /*   we don't want to show that         */
#define STAT_INUSE	(0x0040) /* this job entry is in use             */
#define STAT_SUBJOB	(0x0100) /* job is a subjob                      */

I'm guessing what should happen is something like foregrounding the
SUBLEADER job should also foreground the SUBJOB job.  But that doesn't
tell us whether a job that's not INUSE should show up, or why the INUSE
flag is missing in the first place.

pws