Follow-up: CHECK_JOBS doesn't work when only one command was run since last Control-D

Follow-up: CHECK_JOBS doesn't work when only one command was run since last Control-D

[Andrew Pimlott]

Hey zsh-workers,

Anyone care to take another stab at this old bug?
http://bugs.debian.org/303623

The entire discussion is in the Debian bug log.  Maybe someone will have
a fresh idea in the new decade. ;-)  I just nuked a session with a bunch
of jobs running. :-(  (zsh 4.3.17 in Debian unstable)

Andrew

Re: Follow-up: CHECK_JOBS doesn't work when only one command was run since last Control-D

[Bart Schaefer]

On Apr 18,  4:44pm, Andrew Pimlott wrote:
}
} Anyone care to take another stab at this old bug?
} http://bugs.debian.org/303623

It looks like this behavior has been there since approximately the
beginning of time.  If there was ever an email thread about it, that
thread pre-dates the zsh.org archives that date back to 1995.

However, I think I found some clues, in particular a comment (still
present in Src/jobs.c) that originated in an ancient version of the
shell:

    /* If you immediately type "exit" after "jobs", this      *
     * will prevent zexit from complaining about stopped jobs */

Keep in mind that two exits (or two ctrl+d) in a row are supposed to
cause the shell to exit even if there are running jobs.  In the years
that intervened, code migrated to different files and the *other*
place that sets stopmsg = 2 is now no longer in proximity to that
comment.  That other place is in the handler for ctrl+d.

The rationale seems to be:

1. You type exit (or hit ^D) and the shell says you still have jobs.

2. You type "jobs" to find out what is still running.

3. There's nothing interesting in the jobs list (you just want them
   to die).

4. You type exit (or ^D) again.

5. Zsh deliberately ignores the fact that you ran a command between
   the two exits, and simply goes away without further complaint.

All of this because someone else 17+ years ago was annoyed that the
shell did NOT exit without complaining -- exactly the opposite of the
thing that now annoys you.

I *think*, if we no longer care to provide this particular (mis?)feature,
that it would be OK to remove the "stopmsg = 2" from builtin.c:zexit().
However, I'm not entirely confident there aren't other side-effects.

Re: Follow-up: CHECK_JOBS doesn't work when only one command was run since last Control-D

[Bart Schaefer]

On Apr 18,  9:27pm, Bart Schaefer wrote:
}
} I *think*, if we no longer care to provide this particular (mis?)feature,
} that it would be OK to remove the "stopmsg = 2" from builtin.c:zexit().
} However, I'm not entirely confident there aren't other side-effects.

One possible side-effect being that the shell does not "try again"
when it gets a *real* EOF as opposed to reading a ctrl+d.  (Events in
the opposite order of my speculation in the earlier discussion in that
bug track.)

Re: Follow-up: CHECK_JOBS doesn't work when only one command was run since last Control-D

[Peter Stephenson]

On Wed, 18 Apr 2012 21:27:00 -0700
Bart Schaefer <schaefer@brasslantern.com> wrote:
> 1. You type exit (or hit ^D) and the shell says you still have jobs.
> 
> 2. You type "jobs" to find out what is still running.
> 
> 3. There's nothing interesting in the jobs list (you just want them
>    to die).
> 
> 4. You type exit (or ^D) again.
> 
> 5. Zsh deliberately ignores the fact that you ran a command between
>    the two exits, and simply goes away without further complaint.
> 
> I *think*, if we no longer care to provide this particular (mis?)feature,
> that it would be OK to remove the "stopmsg = 2" from builtin.c:zexit().
> However, I'm not entirely confident there aren't other side-effects.

It should surely be possible to fix it properly, somehow, so that if
you've just looked at the jobs it will still exit but if you've executed
anything else it won't.

However, I don't think having to type ^D twice in any case is
particularly bad (though I do recall occasions in the completion system
where Sven spent some time adding features to avoid a user having to
type A WHOLE EXTRA CHARACTER).

pws


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog

Re: Follow-up: CHECK_JOBS doesn't work when only one command was run since last Control-D

[Bart Schaefer]

On Apr 19,  9:36am, Peter Stephenson wrote:
}
} It should surely be possible to fix it properly, somehow, so that if
} you've just looked at the jobs it will still exit but if you've executed
} anything else it won't.

Yes, that would be accomplished by removing stopmsg = 2 from zexit() but
leaving stopmsg = 2 in bin_jobs().

However, as I mentioned in follow-up, I fear the assignment in zexit()
may have an additional purpose, such as forcing the shell to get two
consecutive zero-length reads on SHIN in order to kill jobs and exit.
It's a little tricky to test this and I haven't had a chance yet.

-- 
Barton E. Schaefer

Re: Bug#303623: Follow-up: CHECK_JOBS doesn't work when only one command was run since last Control-D

[Andrew Pimlott]

Nice archeology, guys. ;)  I'm grateful to you for checking this out.  I
bet at least a couple other people have experienced this and not known
what hit them.  (Your terminal window is gone, you're in shock: you
probably can't reconstruct how it happened.)

Regarding the idea that "if you've just looked at the jobs it will still
exit", I would argue against that.  It seems like a surprise case to me,
and I'd prefer the extra protection and consistency.  But if that's the
way it's always been meant to work, I can understand it.

Andrew