Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: zsh-3.0.3: another problem in Src/jobs.c



> 20 (or June 19 in GMT).  You have made a right choice at last
> for the present implementation for the time being! (I knock on
> wood here :-)
> 
> However, I am afraid I must say something still goes wrong.  Try
> this:
> 	% emacs -nw &
> 	% fg
> 	[type ^X^C to terminate the emacs]
> 	% stty
> 
> 	[Note: this is not artificial.  When you forget to set
> 	 DISPLAY, you will be put in the same situation.]
> 
> As you see, the tty setting remains sane as long as you suspend
> or continue the emacs job.  Once you terminate the job, the tty
> setting goes bad.
> 
> If solely my patch of June 20 had applied, then this is not
> happend when you _once_ suspend the "fg"ed emacs job before
> terminate it.  Now that you also changed Src/jobs.c from

But it did happed when you did not suspend the fg'ed job, even with your
patch, right?

> 
> 	if (jn->stty_in_env && !jn->ty) {
> 	    jn->ty = (struct ttyinfo *) zalloc(sizeof(struct ttyinfo));
> to
> 	if (shout && job == thisjob) {
> 	    if (!jn->ty)
> 		jn->ty = (struct ttyinfo *) zalloc(sizeof(struct ttyinfo));
> 
> in lines 140-142, the problem was revealed.  In zsh-3.0.4, it
> happens whether you have once suspended the job or not.

Still I think zsh is right here, and it is an emacs bug.  The problem is
emacs leaves the tty setting in a wrong state when it exits.  I do not
know how zsh can help here.  Note that ksh does the same, even worse,
since after this the ksh line editor becomes unusable, and I had to kill
ksh from an other terminal.

Zoltan



Messages sorted by: Reverse Date, Date, Thread, Author