earle@smeagol.UUCP (Greg Earle) (02/04/86)
I have a question about GNU Emacs' processing of SIGHUP. On three occasions, while running emacs via remote logged-in terminal (over a modem line), I have had the carrier suddenly drop on me. In each of these occasions, subsequent efforts to re-dial in have been futile; the modem will not answer the phone, indicating the process is hung. An analysis of the most recent event was interesting: last(1) indicated that I had been logged in from 3:02pm Sun. 2/2, until 6:10am Mon. 2/3. lastcomm(1) indicated that the contents of my .logout file were executed at 6:10am. However, I did not logout (I was asleep!), and when I asked all the early-birds at work if they had noticed the modem hung and killed the processes, everyone said no. So, I have no idea how I even got logged out in the first place ... lastcomm(1) indicated that emacs supposedly exited at 3:14pm Sun., (last field in lastcomm(1) output) which, if I could only remember, seems like a reasonable time for the dropped carrier. However, the CPU time attributed to the process was 17 seconds shy of 14 hours!!! (Total login time, 15:07) I notice the fatal signal handler in dist/src/emacs.c checks to see if it is already inside an 'abort in progress'; if not, it cleans up things and then sends the same signal back to itself to accomplish the kill; after having reset the signal's handler to SIG_DFL. This seems reasonable; I *am* curious as to why this is done instead of exit(). I am merely trying to see if a correlation can be made between the port being hung and the emacs task, for whatever reason. Wrench-in-the-monkeyworks dept.: There was one other time, when I had logged in as root and su'ed to myself via 'su earle', that I ran emacs (thru the su subshell); the same thing happened - i.e., carrier dropped; this time, though, everything recovered properly, and any/all processes (incl. emacs) properly terminated, and I was able to subsequently re-login again!!! Wierd... Any theories? Also (unrelated), is there a termcap-controllable solution to this nagging problem: My home terminal uses the '\E=%+ %+ ' method of cursor motion control. In Emacs, whenever I try to execute a Meta command, it always attempts to display the 'ESC' in the minibuffer, no matter how quickly I follow the ESC with the second keystroke. Unfortunately, somehow the echoed escape is getting swallowed; at point, I see "=7 ESC" for instance, as it is trying to send the sequence to go down to row 23, column 1. The terminal manual doesn't say anything about ESC ESC being meaningful. Other prefixes, like C-x, work fine (i.e, properly displayed at correct location in minibuffer if next character not entered in time). I have tried adding padding before the cm string, and it doesn't help. Needless to say, this makes it aggravating to use; for most things I *have* to have emacs (like when I've *got* to have split windows to reference 1 file while I edit another). Configuration: Sun 2/120, Sun V. 2.0 OS (4.2BSD) GNU Emacs V. 17.36 [Home terminal is a Soroc IQ140 - partial emulation of adm3a + own] Any help from anywhere appreciated!! -- Greg Earle JPL Spacecraft Data Systems group sdcrdcf!smeagol!earle (UUCP) ia-sun2!smeagol!earle@csvax.caltech.edu (ARPA)