Xref: utzoo comp.emacs:8392 gnu.emacs:2937 comp.unix.i386:5491
Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!rpi!uupsi!sunic!dkuug!freja.diku.dk!kimcm
From: kimcm@diku.dk (Kim Christian Madsen)
Newsgroups: comp.emacs,gnu.emacs,comp.unix.i386
Subject: Re: GNUemacs Murder-Suicide under BASH
Keywords: GNU emacs bash fatal error
Message-ID: <1990May31.225005.14779@diku.dk>
Date: 31 May 90 22:50:05 GMT
References: <1990May26.054523.19453@rancho.uucp>
Organization: Department Of Computer Science, University Of Copenhagen
Lines: 27

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