From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25757 invoked by alias); 8 Aug 2011 18:52:44 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 29658 Received: (qmail 23727 invoked from network); 8 Aug 2011 18:52:40 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 Received-SPF: neutral (ns1.primenet.com.au: 74.125.82.171 is neither permitted nor denied by SPF record at ntlworld.com) X-ProxyUser-IP: 86.27.188.118 Date: Mon, 8 Aug 2011 19:27:20 +0100 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Re: How to misplace an entire pipeline Message-ID: <20110808192720.380a3ee7@pws-pc.ntlworld.com> In-Reply-To: <110807210507.ZM28821@torch.brasslantern.com> References: <110805203111.ZM32508@torch.brasslantern.com> <20110807185002.6a042cab@pws-pc.ntlworld.com> <110807144359.ZM27903@torch.brasslantern.com> <110807210507.ZM28821@torch.brasslantern.com> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.4; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Sun, 07 Aug 2011 21:05:07 -0700 Bart Schaefer wrote: > The following is clearly not a complete fix and maybe is even wrong if > a different problem is fixed elsewhere, but this at least allows the > suspended pipeline to be manipulated with jobs/fg/bg/wait. > > --- ../zsh-forge/current/Src/exec.c 2011-07-27 01:13:48.000000000 -0700 > +++ Src/exec.c 2011-08-07 19:07:59.000000000 -0700 > @@ -2845,7 +2845,9 @@ > /* This is a current shell procedure that didn't need to fork. * > * This includes current shell procedures that are being exec'ed, * > * as well as null execs. */ > - jobtab[thisjob].stat |= STAT_CURSH|STAT_NOPRINT; > + jobtab[thisjob].stat |= STAT_CURSH; > + if (!jobtab[thisjob].procs) > + jobtab[thisjob].stat |= STAT_NOPRINT; > } else { > /* This is an exec (real or fake) for an external command. * > * Note that any form of exec means that the subshell is fake * Looks fairly plausible, anyway. > When "read" is the tail of the pipe, the above all happens behind the > scenes and then the I/O system call gets restarted, which is how the > shell ends up stuck. I'm not sure how to escape from that, except > maybe to have zhandler() kill the shell with a different signal from > which the system call will not recover. I suppose so. I can hardly believe this ever worked. > When something like "true" is the tail of the pipe, we return into > execpline at line 1500 (from waitjobs()), where list_pipe_job is set > but list_pipe and list_pipe_child are not. If all three were nonzero, > a dummy shell would be forked off as PWS described to act as the > suspended job, but instead execpline() simply returns because the > last job in the pipeline has exited. > > The only obvious thing I can think to do here is to note in zhandler() > that we have STAT_CURSH but not list_pipe, and therefore SIGCONT the > left-hand-side immediately and return as if no signal had occurred > (possibly printing a warning about not being able to suspend the job, > which is what happens elsewhere if pipe() or fork() fails). However, > that could lead to a serious busy-loop if somehow TTIN or TTOU was > the signal instead of TSTP. But we can test if it's TSTP (or STOP)? There are so many special cases here --- there's one for each state the current shell might be in during the process, each of which would be handled straighforwardly if the processing was in another shell --- that even if it sometimes worked before it's not that surprising if it's sensitive to knock-on effects. I suppose it would be nice to be able to test the things that seem to be working, at least, which would need some care and probably a bit of extra test framework. -- Peter Stephenson Web page now at http://homepage.ntlworld.com/p.w.stephenson/