From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7413 invoked from network); 1 Mar 2003 18:42:18 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 1 Mar 2003 18:42:18 -0000 Received: (qmail 3377 invoked by alias); 1 Mar 2003 18:42:12 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 18317 Received: (qmail 3364 invoked from network); 1 Mar 2003 18:42:11 -0000 Received: from localhost (HELO sunsite.dk) (127.0.0.1) by localhost with SMTP; 1 Mar 2003 18:42:11 -0000 X-MessageWall-Score: 0 (sunsite.dk) Received: from [4.64.233.231] by sunsite.dk (MessageWall 1.0.8) with SMTP; 1 Mar 2003 18:42:11 -0000 Received: (from schaefer@localhost) by candle.brasslantern.com (8.11.6/8.11.6) id h21IgAx00838 for zsh-workers@sunsite.dk; Sat, 1 Mar 2003 10:42:10 -0800 From: "Bart Schaefer" Message-Id: <1030301184210.ZM837@candle.brasslantern.com> Date: Sat, 1 Mar 2003 18:42:10 +0000 In-Reply-To: <87smuaw1o9.fsf_-_@ceramic.fifi.org> Comments: In reply to Philippe Troin "Help needed with execcmd() (was: Re: Cant fg a suspended su (4.1.0-dev-7))" (Feb 27, 12:47am) References: <200302211807.h1LI74n23531@aragorn.cortexmachina.com> <1030222230416.ZM10265@candle.brasslantern.com> <87n0kl19el.fsf@ceramic.fifi.org> <87smuaw1o9.fsf_-_@ceramic.fifi.org> X-Mailer: Z-Mail (5.0.0 30July97) To: zsh-workers@sunsite.dk Subject: Re: Help needed with execcmd() (was: Re: Cant fg a suspended su (4.1.0-dev-7)) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Feb 27, 12:47am, Philippe Troin wrote: } Subject: Help needed with execcmd() (was: Re: Cant fg a suspended su (4.1. } } Could somebody familiar with Src/exec.c point out for me where I can } insert a statement where the following conditions are true: I'm not sure I can tell you that, but ... } - I can find out if we are doing a real exec(), not a "fake" exec } (BTW, what's a "fake" exec?) A "fake" exec means that the current shell has state that must explicitly be cleaned up after the external command begins, so the shell can't just replace its process image with that of the new process. Instead it forks, but then [eventually] exits to simulate an exec having taken place. As noted in one of the comments in exec.c, this is similar to the case where the command to be exec'd is a builtin. } following a "exec blah" command } line. For example, in execcmd(), I can find this out with the } do_exec variable. The shell will never do a real exec on do_exec false, but do_exec true does not imply the opposite. A fake exec could still occur. If you're in the code beyond the comment that reads /* Make a copy of stderr for xtrace output before redirecting */ then (is_exec == 1 && forked == 0) means it's a real exec; before the big comment about "Do we need to fork?" the test is more complex. } - the terminal (SHTTY) is still open This should be true any time SHTTY > -1. } - there will be no more terminal or process group ids changes before } we hit zexecve() (meaning no more attachtty(), nor setpgrp()) } } I can't seem to find a spot where all three conditions are true. I'm not 100% certain, but I don't think there is a spot where all three conditions are true, because of the side-effects of the STTY environment variable. There may be a spot where all three plus "STTY is not set" are true, but it'd have to be after all the redirections have been processed, so probably it's never true until somewhere inside the execute() function.