Re: Using "source" in a function breaks job control

[Peter Stephenson <p.stephenson@xxxxxxxxxxx>]

On Fri, 24 Apr 2015 09:21:30 -0700
Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> 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