rock@rancho.uucp (Rock Kent) (05/26/90)
I have GNU Emacs 18.55 running under BASH version 1.05 on an 80386 machine running System V Release 3. While I'm happy with them individually, they have an aggravating habit when working together. The first time I hit ^G in emacs in order to abort an extended command everything is OK. The second time, though, a signal is somehow passed on the bash causing both emacs and bash to terminate leaving only the message "Fatal error (1).". If you've encountered and solved this problem, I would really appreciate some pointers. My fingers, having spent considerable time in adjusting autonomic reactions to the demands of emacs, are too often getting to the ^G before my brain can intervene. :-) Thanks. *************************************************************************** *Rock Kent rock@rancho.uucp POB 8964, Rancho Sante Fe, CA. 92067* ***************************************************************************
kimcm@diku.dk (Kim Christian Madsen) (06/01/90)
rock@rancho.uucp (Rock Kent) writes: >I have GNU Emacs 18.55 running under BASH version 1.05 on an 80386 >machine running System V Release 3. Same here, just running on a MC68030 running System V/68 R3V6 (Motorola port of AT&T UNIX System V Release 3.1 (I think)) >While I'm happy with them individually, they have an aggravating habit >when working together. The first time I hit ^G in emacs in order to >abort an extended command everything is OK. The second time, though, >a signal is somehow passed on the bash causing both emacs and bash to >terminate leaving only the message "Fatal error (1).". I've seen others having this problem as well, and someone indicating that the bash didn't react properly to System V signals. But lacking the time to investigate the source code myself, I hereby make a request to the authors of bash or others willing to correct this misbehaving, to post fixes to the net. It is really awful to see such a good shell as bash be abandoned (as I have done, at least temporary) just because of this strange behaviour in company with emacs. Best Regards Kim Chr. Madsen kimcm@diku.dk
tih@barsoom.nhh.no (Tom Ivar Helbekkmo) (06/01/90)
OK, since there's been several postings about this since we posted our fix to gnu.bug.bash, here's a repost. This will fix the bash/emacs ^G problem for SCO Unix V/386 at least... Bash version number: 1.05 with the March 11th patches. Hardware: Trident 386 (25Mhz/8Mb/330Mb) Operating system: SCO Unix V/386 3.2.0 Compiler: GCC 1.37.1 Description: Coredump in "history", signal fumbling kills shell. Reproduction: Type "history", or start EMACS and say ^G^G. A friend of mine and myself have just gotten bash up and running under SCO Unix V/386 (don't laugh!), and we've had to change a couple of things to make it work under this environment. We believe the changes that were necessary constitute real bugs in bash, so I'm describing them here... Sorry about this not being in patch format -- but I figure you'd like to study it before doing anything with it anyway, so... :-) One of them is in the patches that came out the other day... In the history patch, you say (my arrowed comments): } } <--- This should be... + if (strcmp (list->word->word, "-s") == 0) + { + extern int history_expand (); + char *expanded; + int rval; + + list = list->next; + + while (list) + { + rval = history_expand (list->word->word, &expanded); + printf ("%s", expanded); + fflush (stdout); + + if (rval == -1) + return (EXECUTION_FAILURE); + + free (expanded); + + list = list->next; + } + } + <--- ...here! limit = get_numeric_arg (list); if (limit < 0) limit = -limit; ...which is wrong, since the curly brace my first arrow points to should be where the second arrow is. This makes the "history" builtin coredump the shell, which is hardly what one wants... :-) Other fixes that were needed have to do with signal handling. It doesn't show up so easily, but with GNU EMACS we discovered that the editor would go "Fatal error. (1)" the *second* time Ctrl-G was hit during an editing session. It turned out that bash got confused over the signals that EMACS uses for Ctrl-G aborts. First, nojobs.c. Here's how our file now looks at the point where signals are first initialized: initialize_job_signals () { extern int login_shell; #ifdef notdef extern sighandler throw_to_top_level (); signal (SIGINT, throw_to_top_level); #else extern sighandler sigint_sighandler (); signal (SIGINT, sigint_sighandler); #endif signal (SIGQUIT, SIG_IGN); Then there's shell.c. Same stuff going on, here's what our sigint_sighandler looks like (we've inserted the re-trapping of the signal at the start of the function, and declared the parameter sig for it to use: sighandler sigint_sighandler (sig) int sig; { signal(sig, sigint_sighandler); if (interrupt_immediately) { interrupt_immediately = 0; throw_to_top_level (); } if (!interrupt_state) interrupt_state++; } Finally, a fix is needed in parse.y. Still the same problem, this is just part of the corrections above. We change a declaration and a call to use sigint_sighandler: yy_readline_get () { if (!current_readline_line) { char *readline (); SigHandler *old_sigint; #ifdef notdef extern sighandler throw_to_top_level (); #else extern sighandler sigint_sighandler (); #endif if (!readline_initialized_yet) { initialize_readline (); readline_initialized_yet = 1; } #ifdef notdef old_sigint = (SigHandler *)signal (SIGINT, throw_to_top_level); #else old_sigint = (SigHandler *)signal (SIGINT, sigint_sighandler); #endif -tih -- Tom Ivar Helbekkmo, NHH, Bergen, Norway. Telephone: +47-5-959205 tih@barsoom.nhh.no, thelbekk@norunit.bitnet, edb_tom@debet.nhh.no -- Tom Ivar Helbekkmo, NHH, Bergen, Norway. Telephone: +47-5-959205 tih@barsoom.nhh.no, thelbekk@norunit.bitnet, edb_tom@debet.nhh.no