Serious problem with job control and functions

Serious problem with job control and functions

[Bart Schaefer]

This must be related to the patch from 14327.

I have a shell function:

    man () {
        command man $* | less -ais
    }

I discovered today that if I suspend this function with control-Z, it
vanishes entirely from the job tables and the `man' and `less' commands,
though stopped, are orphaned.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

RE: Serious problem with job control and functions

[Andrej Borsenkow]

>
> This must be related to the patch from 14327.
>
> I have a shell function:
>
>     man () {
>         command man $* | less -ais
>     }
>
> I discovered today that if I suspend this function with control-Z, it
> vanishes entirely from the job tables and the `man' and `less' commands,
> though stopped, are orphaned.
>

I am not sure if it is releated but I recently found that using some shell
functions in xterm window on Mandrake cooker kills this window. It was funny
to see xterm disappearing after 'prompt -p bart' :-) It may be related to
some signal handling/job control. The Mandrake distro corresponds to
4.0.1-pre-5.

-andrej

Re: Serious problem with job control and functions

[Sven Wischnowsky]

Bart Schaefer wrote:

> This must be related to the patch from 14327.

Yes, it is.

> I have a shell function:
> 
>     man () {
>         command man $* | less -ais
>     }
> 
> I discovered today that if I suspend this function with control-Z, it
> vanishes entirely from the job tables and the `man' and `less' commands,
> though stopped, are orphaned.

As a short reminder: 14327 tried to fix the messed up job assignment for
a loop like:

  for i in foo bar; do cat & wait; done

The shell reported that as if one of the cats were on the left hand side
of a pipe because list_pipe_job pointed to it.

Before 14327 we were discussing other ways to try to fix that, esp.
passing the information that the cats were started in the background up
to the execpline() that set list_pipe_job.  What I should have seen when
I wrote 14327 but didn't is that we don't need to pass the information
up.  At that time list_pipe_job has already been set so we only need to
conditionally reset list_pipe_job to zero (if the job we are currently
setting up is started in the background and if it is the one we are
useing as the list_pipe_job).  That's what the patch below does, plus
taking back what 14327 did.

At least for me all the different things we were discussing work now.

Bye
  Sven

Index: Src/exec.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/exec.c,v
retrieving revision 1.27
diff -u -r1.27 exec.c
--- Src/exec.c	2001/05/14 08:51:59	1.27
+++ Src/exec.c	2001/05/28 08:46:34
@@ -976,13 +976,16 @@
         list_pipe_pid = 0;
 	nowait = 0;
 	simple_pline = (WC_PIPE_TYPE(code) == WC_PIPE_END);
-	list_pipe_job = (simple_pline ? 0 : newjob);
+	list_pipe_job = newjob;
     }
     lastwj = lpforked = 0;
     execpline2(state, code, how, opipe[0], ipipe[1], last1);
     pline_level--;
     if (how & Z_ASYNC) {
 	lastwj = newjob;
+
+        if (thisjob == list_pipe_job)
+            list_pipe_job = 0;
 	jobtab[thisjob].stat |= STAT_NOSTTY;
 	if (slflags & WC_SUBLIST_COPROC) {
 	    zclose(ipipe[1]);

-- 
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de