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

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Apr 22, 10:26pm, Peter Stephenson wrote:
} Subject: Re: Using "source" in a function breaks job control
}
} > 1. echo true > /tmp/foo.zsh
} > 2. vi() { source /tmp/foo.zsh; vim -u NONE -N; }
} > 3. Run "vi"
} > 4. In Vim, press Ctrl-Z to put it into the background.
} > 5. Execute "fg".
} > 
} > It should bring back "vim", but does not.
} 
} I'm not going to get any further with this tonight, but using a build to
} instrument process group handling I posted a few weeks ago it seems that
} in the failing case the terminal doesn't get reattached to the vim
} process when the shell function is brought to the foreground.

It's not the "."/"source" command itself that's the problem, because it
works fine as long as the sourced file does not execute any commands.

vi() { source =(<<<'# Nothing here'); vim -u NONE -N }

suspends/restarts fine.

} In the failing case,
} 
} There's no attachtty to 21065.  Handling of SIGCONT within the subshell?

I don't think so ...  the fact that it prints

zsh: running

when you suspend it, indicates that pn->status == SP_RUNNING when passing
through printjob().  Also (though perhaps not definitive), a TRAPCONT()
handler does not fire in the subshell.

It behaves differently (but still wrong) if the "source" file runs an
external command:

torch% vi() { source =(<<<'/bin/true'); vim -u NONE -N }
torch% vi
zsh: suspended  
torch% fg 
[4]    continued  
torch% 

So there it believes WIFSTOPPED(pn->status) is true, but it still brings
the wrong job into the foreground.  (Actually there's a race condition
here, if I "watch thisjob" with gdb I sometimes get "zsh: running" for
an external command.)

Finally you'll note that it has lost the jobtext in the failing case
above, but in the successful case:

torch% vi() { source =(<<<'# /bin/true'); vim -u NONE -N }
torch% vi
zsh: suspended  vi
torch% 

It has something to do with tracking the job table.