Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: Bug+patch: zsh fails to set itself as process group leader when running interactively
- X-seq: zsh-workers 17860
- From: Philippe Troin <phil@xxxxxxxx>
- To: zsh-workers@xxxxxxxxxx
- Subject: Re: Bug+patch: zsh fails to set itself as process group leader when running interactively
- Date: 25 Oct 2002 20:06:02 -0700
- In-reply-to: <87fzuuaq5h.fsf@xxxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
- References: <87fzuuaq5h.fsf@xxxxxxxxxxxxxxxx>
- Sender: Philippe Troin <phil@xxxxxxxx>
Philippe Troin <phil@xxxxxxxx> writes:
> Found in 4.0.6 (and earlier).
>
> If zsh is spawned interactively from another program, it fails to
> establish itself as a process group leader, leading to deliveries of
> terminal-related signals to both zsh and its parent. Generally the
> parent dies, leaving two shells reading from the same terminal.
As a follow-up to myself...
I've also found in init.c:init_signals() the following piece of code:
if (jobbing) {
long ttypgrp;
while ((ttypgrp = gettygrp()) != -1 && ttypgrp != mypgrp)
kill(0, SIGTTIN);
if (ttypgrp == -1) {
opts[MONITOR] = 0;
} else {
signal_ignore(SIGTTOU);
signal_ignore(SIGTSTP);
signal_ignore(SIGTTIN);
attachtty(mypgrp);
}
}
It's probably unnecessary and duplicate code in init_io() and should
be replaced by:
if (jobbing) {
signal_ignore(SIGTTOU);
signal_ignore(SIGTSTP);
signal_ignore(SIGTTIN);
}
Phil.
Messages sorted by:
Reverse Date,
Date,
Thread,
Author