[319] in Athena Bugs
Re: ^C in csh (6.0 machines)
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Tue May 3 23:08:02 1988
Date: Tue, 3 May 88 22:36:49 EDT
From: Theodore Ts'o <tytso@ATHENA.MIT.EDU>
To: John D. Kubiatowicz <kubitron@ATHENA.MIT.EDU>
Cc: bugs@ATHENA.MIT.EDU, henry@ATHENA.MIT.EDU
In-Reply-To: John D. Kubiatowicz's message of Tue, 03 May 88 21:05:34 EDT,
Reply-To: tytso@ATHENA.MIT.EDU
Date: Tue, 03 May 88 21:05:34 EDT
From: John D. Kubiatowicz <kubitron@ATHENA.MIT.EDU>
The bottom line here is that the shell is not always catching the SIGINT.
I broke out of the above loop by hitting ^C several times in succession.
In the past, I have had instances where the shell would not break,
reguardless of the speed with which I hit ^C.
This is something we would have to take up with Berkeley --- I just
tried it on a version 3.0.4.1 workstation, running generic Berkeley
/bin/csh --- the "misfeature" is there. I'm not, however, convinced
that it is a bug; it may be designed that way. The tty process group /
signal code is so convoluted that it will be a while before I can figure
out 1) whether it is intentional or not and 2) if it is a bug, what the
fix is.
I could see an argument made that this is what should happen. Why
should the ^C propagate? The current process (dd) is running; ^C stops
it, and it exits with a zero status code. Naturally, the repeat
continues onward. Consider "repeat 200 <interactive program>". You
exit the interactive program with ^C. Should the repeat die or not?
Actually, I don't buy these arguments much; (I'm playing devil's
advocate here) but the point is that it should not automatically be
considered a bug.
- Ted
