From: Peter Stephenson <p.stephenson@samsung.com>
To: Zsh Hackers' List <zsh-workers@zsh.org>
Subject: Re: Using "source" in a function breaks job control
Date: Tue, 28 Apr 2015 11:18:51 +0100 [thread overview]
Message-ID: <20150428111851.438fdc50@pwslap01u.europe.root.pri> (raw)
In-Reply-To: <150424092130.ZM29016@torch.brasslantern.com>
On Fri, 24 Apr 2015 09:21:30 -0700
Bart Schaefer <schaefer@brasslantern.com> 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
next prev parent reply other threads:[~2015-04-28 10:19 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-22 18:11 Daniel Hahler
2015-04-22 20:41 ` Peter Stephenson
2015-04-22 21:26 ` Peter Stephenson
2015-04-23 4:55 ` Bart Schaefer
2015-04-23 20:13 ` Peter Stephenson
2015-04-24 6:22 ` Bart Schaefer
2015-04-24 15:25 ` Peter Stephenson
2015-04-24 15:43 ` Peter Stephenson
2015-04-24 16:21 ` Bart Schaefer
2015-04-27 17:29 ` Peter Stephenson
2015-04-28 10:18 ` Peter Stephenson [this message]
2015-04-28 15:57 ` Bart Schaefer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150428111851.438fdc50@pwslap01u.europe.root.pri \
--to=p.stephenson@samsung.com \
--cc=zsh-workers@zsh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).