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