markl@oracle.COM (Croaker the Physician) (11/29/89)
We are running GNU emacs 18.55 on both SUN SPARC SUNOS 4.0.3 and DEC 3100 Ultrix workstations. When emacs is invoked from a subshell on these machines, it hangs; PS shows it to be in state "T" (stopped on tty output?). When the same emacs is invoked with the DISPLAY environment variable set appropriately, it creates an X window and all is well. I have the feeling I'm missing something obvious here; does anyone know why this is happening? Thanks,
markl@oracle.COM (Croaker the Physician) (11/29/89)
We are running GNU emacs 18.55 on both SUN SPARC SUNOS 4.0.3 and DEC
3100 Ultrix workstations. When emacs is invoked from a subshell on
these machines, it hangs; PS shows it to be in state "T" (stopped on
tty output?). When the same emacs is invoked with the DISPLAY
environment variable set appropriately, it creates an X window and all
is well. I have the feeling I'm missing something obvious here; does
anyone know why this is happening?
Thanks,
markl
----------
Mark L. Lambert
Architecture Group, Network Products Division
Oracle Corporation
Internet: markl%oracle.com@apple.com
markl@oracle.com (if your mailer groks MX records)
UUCP: ...{hplabs,apple,uunet}!oracle!markl
USMail: Oracle Corporation, 20 Davis Dr, Belmont CA 94002
AT&T: (415) 598-5750
"The parts falling off this car are of the finest British quality..."kjones@talos.uucp (Kyle Jones) (11/30/89)
Mark L. Lambert writes: > We are running GNU emacs 18.55 on both SUN SPARC SUNOS 4.0.3 and DEC > 3100 Ultrix workstations. When emacs is invoked from a subshell on > these machines, it hangs; PS shows it to be in state "T" (stopped on > tty output?). My God, I remember this bug being reported a few days after 18.53 was released. Odd that it still isn't fixed. Our solution here has been to run 18.5[12]. These may have other bugs, but none as irritating as this "stopping in a subshell" thing.
eric@mks.com (Eric Gisin) (12/01/89)
When the process group id is not equal to the process id
on BSD, the SIGIO signals do not get sent to emacs and it hangs.
This happens if your shell does not have job control,
or a sub-shell invokes emacs.
A quick hack is to write a front end to emacs:
main(argc, argv) {
/* set process group to process id */
setpgrp(0, getpgrp(0));
execl(real_emacs, argv);
}
You can also put the setpgrp in emacs' startup
(I'm not sure if this breaks anything).wjc@ho5cad.ATT.COM (Bill Carpenter) (12/01/89)
On 1 Dec 89 01:18:23 GMT, eric@mks.com (Eric Gisin) said: eric> When the process group id is not equal to the process id eric> on BSD, the SIGIO signals do not get sent to emacs and it hangs. eric> This happens if your shell does not have job control, eric> or a sub-shell invokes emacs. That probably explains why I don't have this problem. The original poster was running GNUemacs 18.55 on a Sun4 with SunOS 4.0.3. Same here, but we don't have the hanging subshell problem (we did in the earlier release ... 18.52 or 18.53). The difference is probably that our GNUemacs was built under the SysV emulation environment, which I expect the majority of SUN users don't use. One of the things that is quite different under two compilation environments is some aspects of signal handling. [Note: I'm not particularly advocating the SysV emulation stuff. It just happens to be what we use for our regular stuff around here. It didn't seem to break GNUemacs, so I never bothered to build it the BSD way.] -- Bill Carpenter att!ho5cad!wjc or attmail!bill