Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: "echo | ps -j $(:) | cat | cat | cat" runs components in different process groups
- X-seq: zsh-workers 42516
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: Zsh hackers list <zsh-workers@xxxxxxx>
- Subject: Re: "echo | ps -j $(:) | cat | cat | cat" runs components in different process groups
- Date: Fri, 23 Mar 2018 22:19:59 -0700
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:date:in-reply-to:comments:references:to:subject :mime-version; bh=txa71rmQRKwZRH5+pSJ+f0nEgKEIct6Nm01PEtdJrsw=; b=VteVo4pT8Wt2yocRqkg/QoWyWN4VE9c56vi5ozfgs0glkdCeD+0n5XVP/yR5qVGvPE vQD10KRU/nS1YiF94XmsXOHPc2PzIXqCMmDxWoxS09wHzwqYn5nMfi6KT1JSRMxjtZD2 9BFX21KIcpkFwzDX3P6+a+BoTzP6TLMbmjHxhbmEqMbtjnJxSMevCKfSL0hBaYCdI7At oP7YqGGdVnY0HRAn7qKB8TPcHrgWuidAIWbRO2waWbvZA4QWowhw+KVwoAmlnP6tzPei Zs65YJlrd4+e1eG4NU0wtr6cNhJTrVpDX+S72z8FDAaGY/HYWN4fgRcCppEO2leKm1Hl v6AQ==
- In-reply-to: <180323163614.ZM10192@torch.brasslantern.com>
- List-help: <mailto:zsh-workers-help@zsh.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:zsh-workers@zsh.org>
- List-unsubscribe: <mailto:zsh-workers-unsubscribe@zsh.org>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <20180323161612.GB4857@chaz.gmail.com> <180323163614.ZM10192@torch.brasslantern.com>
On Mar 23, 4:36pm, Bart Schaefer wrote:
}
} Zsh wants to use "echo" as the group leader because it was the first to
} fork, but because $(:) delayed the execution of "ps" the "echo" process
} has already exited and cannot be made group leader. As the fallback the
} other processes each get made into its own process group.
}
} So it's a race condition, adding the process substitution just happens
} to expose it.
It may be this easy?
It fixes the specific example in the subject by causing the zsh parent
shell to re-assume job leader for all subsequent processes in the pipeline
if the current leader is dead. However, I'm concerned that if the first
leader is reaped after a few processes in a long pipeline are created,
there may still be a new process group asserted for remaining processes.
On the other hand I haven't found an example where that occurs, instead
I get jobs where the process group ID is the PID of the now-dead leader.
It could be I just haven't constructed the right test.
In any case "make check" still passes and this appears to be better than
the previous situation.
diff --git a/Src/exec.c b/Src/exec.c
index 35b0bb1..52b0eb4 100644
--- a/Src/exec.c
+++ b/Src/exec.c
@@ -3455,6 +3455,7 @@ execcmd_exec(Estate state, Execcmd_params eparams,
if (type == WC_SUBSH && !(how & Z_ASYNC))
flags |= ESUB_JOB_CONTROL;
filelist = jobtab[thisjob].filelist;
+ list_pipe_child = list_pipe;
entersubsh(flags);
close(synch[1]);
forked = 1;
Messages sorted by:
Reverse Date,
Date,
Thread,
Author