Re: suspend (^Z) behavior while a function is running is unclear

[Vincent Lefevre <vincent@xxxxxxxxxx>]

On 2012-02-20 15:13:09 +0000, Peter Stephenson wrote:
> On Mon, 20 Feb 2012 14:02:59 +0100
> Vincent Lefevre <vincent@xxxxxxxxxx> wrote:
> > BTW, concerning zsh, if the behavior is regarded as correct, a fork
> > is still done even when the suspended command is the last one in the
> > function, e.g.
> > 
> >   foo() { emacs "$@"; }
> 
> There's certainly no good reason for trying to make a special case
> here; it's complicated for very little gain.
> 
> > Is the fork really necessary?
> 
> If you're actually trying to do real, live job control (rather than some
> internal approximation to it), yes, as that operates on processes, and
> (in your example) the shell function is the top-level code you need to
> suspend, regardless of any processes that may also have been started
> from it. I can't tell you if it's necessary for what you thought you
> were trying to do, if it wasn't job control.

Well, I have an emacs wrapper that does various things, then runs
emacs. Thus, when I suspend it or run it in background, there's a
spurious zsh process, which is sometimes a bit confusing. But to
avoid that, perhaps it's better to have a real script, not a zsh
function.

> Index: Doc/Zsh/jobs.yo
> ===================================================================
> RCS file: /cvsroot/zsh/zsh/Doc/Zsh/jobs.yo,v
> retrieving revision 1.5
> diff -p -u -r1.5 jobs.yo
> --- Doc/Zsh/jobs.yo	29 Mar 2006 19:25:15 -0000	1.5
> +++ Doc/Zsh/jobs.yo	20 Feb 2012 15:00:32 -0000
> @@ -37,6 +37,21 @@ when it is typed.
>  
>  A job being run in the background will suspend if it tries to read
>  from the terminal.
> +
> +Note that if the job running in the foreground is a shell function,
> +then suspending it will have the effect of causing the shell to fork.
> +This is necessary to separate the function's state from that of the
> +parent shell performing the job control, so that the latter can return
> +to the command line prompt.  As a result, even if tt(fg) is
> +used to continue the job the function will no longer be part of the
> +parent shell, and any variables set by the function will not be visible
> +in the parent shell.  Thus the behaviour is different from the case
> +where the function was never suspended.  Zsh is is different from many
                                                ^^^^^
duplicate "is"

> +other shells in this regard.
> +
> +The same behaviour is found when the shell is executing code as the
> +right hand side of a pipeline, in order that the entire pipeline
> +can be managed as a single job.
>  cindex(background jobs, I/O)
>  cindex(jobs, background, I/O)
>  Background jobs are normally allowed to produce output,

Now I'm thinking whether there should be an option to control that.
Indeed, some functions may fail to work correctly if they are suspended
in such a way. Some functions or { list } could be marked as not
backgroundable, e.g. by setting an option at the beginning, in which
case the ^Z could be ignored.

What happens if a TSTP signal is received while a completion function
is run or something like that?

-- 
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)