From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29964 invoked by alias); 28 Apr 2015 15:57:16 -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: 34986 Received: (qmail 17510 invoked from network); 28 Apr 2015 15:57:14 -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=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:to:subject:mime-version:content-type; bh=lkuJAZ3Z8fWsmQW96BcXcu5acicHG/Q2JHUTGar6Bjc=; b=hUcnLKR4MSZ3oOXMLZbDC6HmxNDXYmyCQ558eXMx1obvnHUdETvZgAtgNQfB+yhJn1 30bVoZrc3C+Daa6uqIif7KcIbkfErlJFMMwrCJ0tltiiEubLULHMtWkE5rZTEoyHiaf4 M44uHgrISQ1iHM+8s5KQIanKvDuCLAWoBM0KaoWdtGpBstA3mNWTAkx6Bu4VxkFVa2HG iy4X2aFzb4efKTIl9+sJh/f1e49/JmHU4AShqrf2fhmX5dxWe8kfcE8GUWQGEcQYJ1Wz SST/KhCZbLQZ6ygfkLYDxKa/D7dzDEcOfdg/DZzlqAYuOACgtMf8jw/1JX57DK/cFTFp xaAQ== X-Gm-Message-State: ALoCoQm/e1xYTW1FCV1KJRKzOgjbQKt2DexIOlSL/HQYZOWMu5FdqETIrCHOjGfY3+DXco3b+PyR X-Received: by 10.202.210.194 with SMTP id j185mr14156007oig.68.1430236629521; Tue, 28 Apr 2015 08:57:09 -0700 (PDT) From: Bart Schaefer Message-Id: <150428085707.ZM30518@torch.brasslantern.com> Date: Tue, 28 Apr 2015 08:57:07 -0700 In-Reply-To: <20150428111851.438fdc50@pwslap01u.europe.root.pri> Comments: In reply to Peter Stephenson "Re: Using "source" in a function breaks job control" (Apr 28, 11:18am) 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> <20150428111851.438fdc50@pwslap01u.europe.root.pri> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: "Zsh Hackers' List" Subject: Re: Using "source" in a function breaks job control MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Apr 28, 11:18am, Peter Stephenson wrote: } Subject: Re: Using "source" in a function breaks job control } } 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. Ok, that makes perfect sense. For point of contrast, given an equivalent function, bash stops vim but the function immediately continues without stopping; ksh 93u-1 (ubuntu) gets really confused: $ vi() { vim -u NONE -N; echo $?; } $ vi [2] + Stopped vi $ jobs [2] + Stopped vi [1] - Running vi $ Note that $? does not reflect that vim has been suspended. Both jobs are actually stopped even though job 1 still says "Running". $ fg %1 ksh: fg: no such job $ fg vi 0 $ Job 2 is the function, job 1 is vim, but there's no way to bring vim back into the foreground again except: $ ps x | grep vim 20687 pts/0 T 0:00 vim -u NONE -N $ kill -CONT 20687; wait (vim resumes and I can exit from it) $ (Also if I run "vim" directly from the command line and stop it and "echo $?" I get 276 in ksh93, 148 in bash and zsh.) } 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. This also makes sense. } 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. I don't think that's necessary, and it I suspect it creates weird issues when things are backgrounded instead of foregrounded. Documentation is probably sufficient here, it's (emperically) pretty unusual for the user of an interactive shell to care about these exit values as long as all the processes stop and restart in the right order. } 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. Perhaps there's some way to preserve that status without propagating it as the exit of the whole subshell?