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

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

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.