Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: Final (?) info on signals/crashes when suspending "mutt" function
- X-seq: zsh-workers 6883
- From: "Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>
- To: Peter Stephenson <pws@xxxxxxxxxxxxxxxxx>, zsh-workers@xxxxxxxxxxxxxx
- Subject: Re: Final (?) info on signals/crashes when suspending "mutt" function
- Date: Sun, 27 Jun 1999 16:45:28 +0000
- In-reply-to: <9906271321.AA16977@xxxxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxxxxxx; run by ezmlm
- References: <9906271321.AA16977@xxxxxxxxxxxxxxxxx>
On Jun 27, 3:21pm, Peter Stephenson wrote:
} Subject: Re: Final (?) info on signals/crashes when suspending "mutt" func
}
} "Bart Schaefer" wrote:
} > The failure in case (1) is far less catastrophic than case (2), so I think
} > the right solution is to back off to the behavior from patch 6707
}
} Somebody who's been looking at this will have to produce counter-patches
} for pws-24, I'm not going to attempt this myself on a wing and a prayer.
I spent several hours last night attempting it in 3.0.6 and have not been
having much luck. I got it back to the point where suspending the mutt
function doesn't kill the parent, thing, but then it appears (from strace)
that bin_fg() is calling attachtty() with the parent shell's process ID
rather than that of the stopped job, which would mean that someplace that
I haven't found yet, the `gleader' of the job entry is set incorrectly.
(The effect of this is that mutt appears to come into the foreground, but
then gets a SIGTTIN and stops again as soon as it tries to read input.)
I fear I'm going to have to punt this to Sven. I had really hoped to put
out a test 3.0.6 this weekend, but now it may have to wait a couple weeks.
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com
Messages sorted by:
Reverse Date,
Date,
Thread,
Author