Subject: Re: mail signal handling...
To: None <current-users@NetBSD.ORG>
From: der Mouse <mouse@Holo.Rodents.Montreal.QC.CA>
List: current-users
Date: 01/23/1997 15:37:16
> Anyone else still use plain old mail?

Yes, me...though not on NetBSD. :-)  (I don't, yet, handle my mail on
NetBSD; when I do, I'll be using my own UA, loosely patterned after MH.)

> If so, do you notice that ^C to interrupt letters may not work all
> the time?  On my -current system, the first letter I abort works, but
> any further attempts fail; I can only stop a letter by sending it, or
> by killing mail outright.  This is a pain.

The reason I'm replying is that I too have seen some very strange
behavior surrounding ^C (which is in fact my VINTR character).

In particular, sometimes (usually related to typing ^C at times when
"things are changing", as the shell starts an application or as an
application exits) the tty driver gets into a weird state where a ^C is
"hanging fire".  In this state, (a) my shell, which normally does
command-line editing, stops doing command-line editing, instead not
echoing anything until I type RETURN and then echoing the whole thing,
(b) commands built-in to the shell like "set" work normally, aside from
the lack of echo and editing as I type them, (c) programs like ls that
don't attempt to read any input run fine, producing output, though the
shell is still weirded out when they exit, and (d) any program that
tries to read input (cat is the one I canonically run when I notice
this state) get an immediate SIGINT upon starting.  Interestingly, when
a case (d) program starts, not only does the program die with SIGINT,
but I see the ^C echoed to the pseudo-tty!  (I have never seen this
happen on a "real" tty, but I use "real" ttys so seldom this is not

This is almost the opposite of what you're seeing, but they are both
weirdnesses surrounding ^C, so it's hard to think they're entirely

The thing with the shell not doing command-line editing may or may not
be significant.  I have not yet investigated enough to find out whether
(i) the shell decides it's not talking to a tty (it makes this decision
anew each time it goes to read a command line) or (ii) the tty driver
isn't passing the bytes out to userland until an entire line has been
typed.  I currently favor (ii) because _some_ command-line editing
kinda sorta vaguely almost works (even though I get no echo I can do at
least a little by typing blind).

The systems on which this happens are NetBSD/sun3 at approximately 1.2.

					der Mouse

		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B