🚀 go-pugleaf

In article <19900827172514.1.BARMAR@OCCAM.THINK.COM>, barmar@THINK.COM
(Barry Margolin) writes:
|>In GNU Emacs 18.55.15, built under SunOS 4.0.3 (or maybe 4.0) but
|>running on a Sun-4/280 running SunOS 4.1....
|>
|>If I use "m-x shell" in an Emacs process that doesn't have a controlling
|>terminal (for instance, an X windows Emacs started from "rsh") the shell
|>process doesn't get a controlling terminal, and stops immediately with
|>"Process shell stopped (tty input)".  I suspect this is due to SunOS
|>4.1's switch from BSD-style to POSIX-style controlling terminal
|>association.  However, the release manual (p.53-54) claims that most of
|>the canonical ways of getting a controlling terminal are still
|>supported.
|>
|>Will recompiling Emacs in 4.1 fix it automatically, or are code changes
|>necessary?  Is this a bug in Sun's supposed back-compatibility?
|>
|>                                                barmar
                

Same thing happened to us right after we upgraded our SUN4/280 and its
SUN3/60s from 4.0.3 to 4.1. The shell is stopped when 'xemacs' is
started from twm or one's '~/.xsession' by 'xdm'. Works fine when
started from 'xterm'. I asked keith@expo.lcs.mit.edu, here is his answer :

>This is almost certainly a bug in emacs - it is attempting to set up the
>*shell* buffer using the terminal settings inherited from emacs when it
>started, by invoking ioctl on stdin.  When the controlling terminal isn't
>currently controlled by the process invoking ioctl, it blocks "stopped (tty
>input)".  Emacs started from twm or .xsession isn't supposed to have a
>controlling terminal.  Under SunOS 4.1, it looks like this is not quite the
>case; I'd bet that all of these processes are inheriting /dev/console as the
>controlling terminal.

>You'll need to fix emacs.

Ok let's fix emacs!