From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5853 invoked by alias); 28 Apr 2015 10:19:13 -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: 34983 Received: (qmail 5049 invoked from network); 28 Apr 2015 10:19:00 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI, SPF_HELO_PASS autolearn=ham version=3.3.2 X-AuditID: cbfec7f4-f79c56d0000012ee-87-553f5e912b43 Date: Tue, 28 Apr 2015 11:18:51 +0100 From: Peter Stephenson To: Zsh Hackers' List Subject: Re: Using "source" in a function breaks job control Message-id: <20150428111851.438fdc50@pwslap01u.europe.root.pri> In-reply-to: <150424092130.ZM29016@torch.brasslantern.com> References: <5537E450.9060205@thequod.de> <20150422222627.1f6154e9@ntlworld.com> <150422215539.ZM14251@torch.brasslantern.com> <20150423211331.5ea4baf0@ntlworld.com> <20150424162542.2efb36a3@pwslap01u.europe.root.pri> <150424092130.ZM29016@torch.brasslantern.com> Organization: Samsung Cambridge Solution Centre X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.0; i386-redhat-linux-gnu) MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrELMWRmVeSWpSXmKPExsVy+t/xa7oT4+xDDbbe57I42PyQyYHRY9XB D0wBjFFcNimpOZllqUX6dglcGQ/vHmQpOCdY8eJUeQPjB94uRk4OCQETif5Ph9ghbDGJC/fW s4HYQgJLGSWud2l3MXIB2TOYJHYeO8UG4WxjlLjQvIkFpIpFQFXiwotVzCA2m4ChxNRNsxm7 GDk4RAS0Jdo/ioGEhQVsJDbdegk2lFfAXmLnyblgrZwCVhLXP7yAmnmDSWLTlxmMIAl+AX2J q38/MUFcZC8x88oZRohmQYkfk++BNTMLaEls3tbECmHLS2xe85YZ4mp1iRt3d7NPYBSahaRl FpKWWUhaFjAyr2IUTS1NLihOSs811CtOzC0uzUvXS87P3cQICdkvOxgXH7M6xCjAwajEw5vB bB8qxJpYVlyZe4hRgoNZSYS3OBIoxJuSWFmVWpQfX1Sak1p8iFGag0VJnHfurvchQgLpiSWp 2ampBalFMFkmDk6pBsZ59q/zRX5H2DkcF07aM6H7/wdPDsfaee6R/XE5WmcDIlpOu7ZtXcbN o7tQ6+Hqz9sdRaMXSr3zjrzBGnFK6PQHTs/e4qLpyVpKmxVkj6k87luVMMHh9WHziKvFD0sm pf4xb1p3+8jFbRz8/FVhEjcX3z7HosRUwWf+JM3WVqbQxy7r8a4N05RYijMSDbWYi4oTAW0F DvpVAgAA On Fri, 24 Apr 2015 09:21:30 -0700 Bart Schaefer wrote: > torch% fg > [1] + continued > vim exited 148 > torch% > > As you noted a few messages back, this is the exit status from the signal > stop rather than from the actual exit. This is much more basic --- the source has got nothing to do with it and any vim inside a function shows the same effect. I think, in fact, it's down to simple process logic. I tried using vi() { vim -u NONE -N; print "vim exited $?" } and that prints the wrong status if vim was suspended --- despite the fact I can see the status of the vim process being updated in addbgstatus(). Then it occurred to me that actually that's inevitable, if I've understood what's going on. vim was suspended from the parent shell, and remains a child of that --- but we've forked at that point, and the print is going to happen in the forked copy. That can never see the status of the exited vim unless there's some complex communication about process statuses with the parent shell which even the Seeress of the myth didn't foresee. Then it occurred to me that because it hasn't got the updated status of the vim, the subshell will continue for ever more to think it has status 148, so without the "print" it's going to exit with that status when it gets to the end of the function. It's that subshell status that the main shell reports (reasonably enough, you'd have thought) as the overall status of the job. Then I got confused and stopped. We could do some clever stuff with piping status information when we restart the subshell to update it about the exit status of the thing that got suspended. That might not be *that* hairy given that by definition we have control of both main shell and subshell at the point where they get forked and presumably (though I don't know where this is) where the subshell gets retstarted. It would involve more understanding of the list_pipe code than I have, though. A simple alternative might be for the subshell to set the status of the process that caused it to fork to 0. But this breaks any logic depending on the exit status --- at least the 148 tells you something funny is going on. pws