dph@lanl.gov (David Huelsbeck) (03/22/89)
Howdy GNUrus, I just installed GNU Emacs 18.53 on a VAX 11/785 running BSD 4.3, and I'm seeing a problem that I have no idea how to track down. Emacs comes up just fine when it's called from the command line but it hangs when invoked from another program. As an example using the ~e command within mail will cause emacs to stop. (STAT is T when a ps is done.) Any ideas? David Huelsbeck dph@lanl.gov
sethr@cunixc.cc.columbia.edu (Seth Robertson) (03/22/89)
In article <10897@lanl.gov> dph@lanl.gov (David Huelsbeck) writes: >I just installed GNU Emacs 18.53 on a VAX 11/785 running BSD 4.3, The problem is due to a *bug*. The best thing to do is to grab a can of raid. Spray into emacs.c, and remove all (2) lines that say: "setpgrp". In addition, it might well be a good idea if Richard Stallman or some Important Person at MIT/UUNET/etc could modify the code and redistribute the bug-free code to all points of interest. (18.53 1/2) -Seth seth@ctr.columbia.edu
pae@cos.com (Paul A. Ebersman) (03/22/89)
From article <10897@lanl.gov>, by dph@lanl.gov (David Huelsbeck): > I just installed GNU Emacs 18.53 on a VAX 11/785 running BSD 4.3, > and I'm seeing a problem that I have no idea how to track down. > Emacs comes up just fine when it's called from the command line > but it hangs when invoked from another program. As an example using > the ~e command within mail will cause emacs to stop. (STAT is T when > a ps is done.) > I got the same thing installing 18.53 on a Sun running OS3.5 and one running 3.4. (Though I got status P when I did a ps). I tried exec within a shell script, and that worked, but scips the rest of the shell script. And, as expected, if I call the first shell script from another shell script, it also hung. -- Paul A. Ebersman @ Corporation for Open Systems pae@cos.COM or pae%cos.com@uunet.uu.net or {uunet, sundc, hadron}!cos!pae ( The difference between practice and theory in practice is always greater than the difference between practice and theory in theory. )
jr@bbn.com (John Robinson) (03/23/89)
In article <1324@cunixc.cc.columbia.edu>, sethr@cunixc (Seth Robertson) writes: >In addition, it might well be a good idea if Richard Stallman >or some Important Person at MIT/UUNET/etc could modify the code >and redistribute the bug-free code to all points of interest. >(18.53 1/2) Well, gee, I'm not very important or anything, but do you think anyone would mind if I distributed the patch? It's purty small, so I reckon there's no good to sending a new copy of the whole file nowhere. While I'm here, let me add the ChangLog entry that goes with this change. It looks like it was put in with good intentions, but without knowledge of the grim side-effects it would have on shell scripts or other programs that run emacs in inferior forks. I would never do such a thing - rather sit in emacs all day long... Sat Feb 18 09:03:52 1989 Richard Stallman (rms at sugar-bombs.ai.mit.edu) * emacs.c (main) [BSD]: Do setpgrp. May avoid some Unix signal bugs. Here's the change (only one made in emacs.c, so you can undo this by putting your release 18.52 copy of emacs.c into your 18.53 distribution area): diff -rc2N dist-18.52/src/emacs.c dist-18.53/src/emacs.c *** dist-18.52/src/emacs.c Fri Aug 26 18:31:50 1988 --- dist-18.53/src/emacs.c Sat Feb 18 09:03:50 1989 *************** *** 225,228 **** --- 225,233 ---- #endif HIGHPRI + #ifdef BSD + /* interrupt_input has trouble if we aren't in a separate process group. */ + setpgrp (getpid (), getpid ()); + #endif + inhibit_window_system = 0; So it seems that some systems that use interrupt_input will behave worse without this setpgrp() call, so there should be some folks out there would prefer to leave this code in. None as much as owned up yet, though. Just run that feller through patch and remake yer emacs, and this shellscript problem'll be fixed. Shucks. -- /jr jr@bbn.com or bbn!jr C'mon big money!