From: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
To: zsh-workers@sunsite.auc.dk
Subject: Re: Job control bug with pws-25
Date: Mon, 5 Jul 1999 13:06:36 +0200 (MET DST) [thread overview]
Message-ID: <199907051106.NAA07331@beta.informatik.hu-berlin.de> (raw)
In-Reply-To: Peter Stephenson's message of Mon, 05 Jul 1999 11:48:23 +0200
Peter Stephenson wrote:
> Sven Wischnowsky wrote:
> > You didn't miss a patch -- I forgot to play with `bg'. Whew, this was
> > a bit more complicated. So much so, that I finally put some of the
> > things distributed in jobs.c into functions (super_job() and
> > handle_sub()).
>
> Much improved, thanks. There's still a small bug:
>
> % fn() { sleep2; print foo; }
> % fn
> ^Z
> % bg
> % foo
>
> The function exited, but no message was printed; notify is set. Running
> `jobs' or exiting the shell prints the message. Runing fn directly in the
> background behaves as expected. (I think we had something like this once
> before, but I don't think it was there when the current saga started.)
I think the patch below is the right fix. It says roughly that we are
done setting up the super-job once we have turned it into one.
There is still a small problem: sometimes I get an empty line before a
job-status message even when I shouldn't (because it isn't needed). I
haven't found out why the code sometimes thinks it should print that
when it shouldn't (but I consider this problem as being not too
important).
> It seems to me it might be a good idea to collect some of the things which
> can potentially go wrong with job control (as well as some which shouldn't
> :-)) and put them in a file, say, Misc/job-control-tests. It doesn't need
> to run the tests itself, that's far too hard when the bugs are largely
> interactive, just give a collection of code with comments saying what you
> should do to see if it's working. If I get a moment I'll have a look back
> in the archive for some.
Yes, and I'll probably have to put some more comments everywhere.
Unfortunately I'll be very busy this week again.
Bye
Sven
diff -u os/exec.c Src/exec.c
--- os/exec.c Mon Jul 5 12:00:24 1999
+++ Src/exec.c Mon Jul 5 12:58:50 1999
@@ -916,7 +916,7 @@
}
jn->stat &= ~(STAT_DONE | STAT_NOPRINT);
- jn->stat |= STAT_STOPPED | STAT_CHANGED;
+ jn->stat |= STAT_STOPPED | STAT_CHANGED | STAT_LOCKED;
printjob(jn, !!isset(LONGLISTJOBS), 1);
}
else if (newjob != list_pipe_job)
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
next reply other threads:[~1999-07-05 11:07 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-07-05 11:06 Sven Wischnowsky [this message]
-- strict thread matches above, loose matches on Subject: below --
1999-07-05 10:00 Sven Wischnowsky
1999-07-05 9:48 ` Peter Stephenson
1999-07-03 12:19 Peter Stephenson
1999-07-03 13:16 ` Geoff Wing
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=199907051106.NAA07331@beta.informatik.hu-berlin.de \
--to=wischnow@informatik.hu-berlin.de \
--cc=zsh-workers@sunsite.auc.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).