* Odd job-reporting buglet (Re: Change in suspend behavior) [not found] ` <010510153513.ZM24266@candle.brasslantern.com> @ 2001-05-11 4:21 ` Bart Schaefer 2001-05-11 8:47 ` Sven Wischnowsky 0 siblings, 1 reply; 4+ messages in thread From: Bart Schaefer @ 2001-05-11 4:21 UTC (permalink / raw) To: zsh-workers On May 10, 3:35pm, Bart Schaefer wrote: } } for i in bar foo; do mycmd $i & done; wait; fg } } The "wait" is just there to be sure that all the jobs have a chance to } start up (and then stop again on SIGTTOU or SIGTTIN) before the "fg" } is executed. Change that loop just a little bit and some really strange things happen: schaefer[501] for i in bar foo; do cat & wait; done [2] 27451 [2] + suspended (tty input) cat [1] 27452 [1] + suspended (tty input) cat zsh: suspended (tty input) cat | zsh: running for i in bar foo; do; cat & wait; done Eh? It thinks "cat" has been piped to the for loop! Also, how did job number 2 get a smaller process ID than job number 1? schaefer[502] jobs -l [1] + 27452 suspended (tty input) cat | 27453 running for i in bar foo; do; cat & wait; done [2] - 27451 suspended (tty input) cat -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Odd job-reporting buglet (Re: Change in suspend behavior) 2001-05-11 4:21 ` Odd job-reporting buglet (Re: Change in suspend behavior) Bart Schaefer @ 2001-05-11 8:47 ` Sven Wischnowsky 2001-05-11 15:52 ` Bart Schaefer 0 siblings, 1 reply; 4+ messages in thread From: Sven Wischnowsky @ 2001-05-11 8:47 UTC (permalink / raw) To: zsh-workers Bart Schaefer wrote: > ... > > Change that loop just a little bit and some really strange things happen: > > schaefer[501] for i in bar foo; do cat & wait; done > [2] 27451 > [2] + suspended (tty input) cat > [1] 27452 > [1] + suspended (tty input) cat > zsh: suspended (tty input) cat | > zsh: running for i in bar foo; do; cat & wait; done > > Eh? It thinks "cat" has been piped to the for loop! Also, how did job > number 2 get a smaller process ID than job number 1? > > schaefer[502] jobs -l > [1] + 27452 suspended (tty input) cat | > 27453 running for i in bar foo; do; cat & wait; done > [2] - 27451 suspended (tty input) cat Aaarrrrggghhh! The reason is pretty clear (to some): the sub-job returns and is stopped, so execpline() things it has to do all that super/sub-job handling it does when the sub-job was suspended with ^Z. One way to try to fix this is to make execpline() check if the sub-job really was suspended because of a ^Z (SIGTSTP). And only then create a super-job and whatnot. The other way to try to fix this would be to check if the sub-job was ASYNC (i.e. it had a `&' at the end), pass that information up to (the right) execpline() and there decide to not wrap it into a super-job. The patch below (not committed and certainly not to be committed before we've discussed this some more) does the first for me (check for SIGTSTP). I think both solutions have their pros and cons. Opinions? Bye Sven Index: Src/exec.c =================================================================== RCS file: /cvsroot/zsh/zsh/Src/exec.c,v retrieving revision 1.26 diff -u -r1.26 exec.c --- Src/exec.c 2001/03/30 16:51:54 1.26 +++ Src/exec.c 2001/05/11 08:47:30 @@ -1064,11 +1064,26 @@ jn->stat & STAT_DONE && lastval2 & 0200) killpg(mypgrp, lastval2 & ~0200); +#if 0 + /* This does the wrong thing if the sub-job was stopped + * for some other reason than the user hitting ^Z. In that + * case we don't want it to put the whole loop (or whatever) + * into a super-job. */ if (!list_pipe_child && !lpforked && !subsh && jobbing && (list_pipe || last1 || pline_level) && ((jn->stat & STAT_STOPPED) || (list_pipe_job && pline_level && (jobtab[list_pipe_job].stat & STAT_STOPPED)))) { +#endif + if (!list_pipe_child && !lpforked && !subsh && jobbing && + (list_pipe || last1 || pline_level) && + (((jn->stat & STAT_STOPPED) && + WIFSTOPPED(jn->procs->status) && + WSTOPSIG(jn->procs->status) == SIGTSTP) || + (list_pipe_job && pline_level && + (jobtab[list_pipe_job].stat & STAT_STOPPED) && + WIFSTOPPED(jobtab[list_pipe_job].procs->status) && + WSTOPSIG(jobtab[list_pipe_job].procs->status) == SIGTSTP))) { pid_t pid; int synch[2]; -- Sven Wischnowsky wischnow@informatik.hu-berlin.de ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Odd job-reporting buglet (Re: Change in suspend behavior) 2001-05-11 8:47 ` Sven Wischnowsky @ 2001-05-11 15:52 ` Bart Schaefer 2001-05-14 8:50 ` Sven Wischnowsky 0 siblings, 1 reply; 4+ messages in thread From: Bart Schaefer @ 2001-05-11 15:52 UTC (permalink / raw) To: zsh-workers On May 11, 10:47am, Sven Wischnowsky wrote: } } Bart Schaefer wrote: } } > schaefer[501] for i in bar foo; do cat & wait; done } > [2] 27451 } > [2] + suspended (tty input) cat } > [1] 27452 } > [1] + suspended (tty input) cat } > zsh: suspended (tty input) cat | } > zsh: running for i in bar foo; do; cat & wait; done } } The reason is pretty clear (to some): the sub-job returns and is } stopped, so execpline() things it has to do all that super/sub-job } handling it does when the sub-job was suspended with ^Z. This happens only because of the `wait' command, right? It does *not* happen when I do `for i in bar foo; do; cat & sleep 5; done'. } One way to try to fix this is to make execpline() check if the sub-job } really was suspended because of a ^Z (SIGTSTP). One can send TSTP with a `kill'. Testing for TSTP has to be combined with a test for whether the job is the foreground job at the time. } The other way to try to fix this would be to check if the sub-job was } ASYNC (i.e. it had a `&' at the end), pass that information up to (the } right) execpline() and there decide to not wrap it into a super-job. That sounds closer to the right thing to me, but wouldn't a test for "is the foreground job" be equivalent (and possibly not need any more info to be passed around)? Or maybe it would be possible to know that we're in a `wait' command and simply not do any of this processing? But that would be equivalent to "is this the foreground job" as well (as the `wait' would be the fore- ground job in that case, not the job that got the signal). -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Odd job-reporting buglet (Re: Change in suspend behavior) 2001-05-11 15:52 ` Bart Schaefer @ 2001-05-14 8:50 ` Sven Wischnowsky 0 siblings, 0 replies; 4+ messages in thread From: Sven Wischnowsky @ 2001-05-14 8:50 UTC (permalink / raw) To: zsh-workers We were both on the wrong track. The code once handled that correctly but then came the change in 6819 that made foo | while true; do bar; done suspendable (with a quickly finishing bar). The change made execpline() test the state of `foo', by adding: (list_pipe_job && pline_level && (jobtab[list_pipe_job].stat & STAT_STOPPED)))) { But in cases like the one we're discussing now, the list_pipe_job was set when starting the loop and ended up pointing to a job in the loop. So the patch below tries to fix this at a completely different place -- setting up list_pipe_job only if we are building a job for a real pipe into a loop or something (not for a loop not inside a pipe). Seems to work for me, without breaking what I said above, so I'm going to commit it. Bye Sven Index: Src/exec.c =================================================================== RCS file: /cvsroot/zsh/zsh/Src/exec.c,v retrieving revision 1.26 diff -u -r1.26 exec.c --- Src/exec.c 2001/03/30 16:51:54 1.26 +++ Src/exec.c 2001/05/14 08:49:23 @@ -973,10 +973,10 @@ * stopped, the top-level execpline() didn't get the pid for the * sub-shell because it was overwritten. */ if (!pline_level++) { - list_pipe_job = newjob; list_pipe_pid = 0; nowait = 0; simple_pline = (WC_PIPE_TYPE(code) == WC_PIPE_END); + list_pipe_job = (simple_pline ? 0 : newjob); } lastwj = lpforked = 0; execpline2(state, code, how, opipe[0], ipipe[1], last1); -- Sven Wischnowsky wischnow@informatik.hu-berlin.de ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2001-05-14 8:50 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <20010510195228.018E6DCC4@mail.cise.ufl.edu> [not found] ` <010510153513.ZM24266@candle.brasslantern.com> 2001-05-11 4:21 ` Odd job-reporting buglet (Re: Change in suspend behavior) Bart Schaefer 2001-05-11 8:47 ` Sven Wischnowsky 2001-05-11 15:52 ` Bart Schaefer 2001-05-14 8:50 ` Sven Wischnowsky
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).