[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#9620: dd: bogus behavior when interrupted
From: |
Alan Curry |
Subject: |
bug#9620: dd: bogus behavior when interrupted |
Date: |
Tue, 27 Sep 2011 16:32:24 -0500 (GMT+5) |
=?UTF-8?Q?P=C3=A1draig?= Brady writes:
>
> BTW that ^C being displayed (started around Fedora 11 time (2.6.30))
> is very annoying, especially when inserted in the middle of an ANSI code.
> I mentioned that previously here:
> http://mail.linux.ie/pipermail/ilug/2011-February/106723.html
I've been annoyed by that too. So annoyed that I patched my kernel to get rid
of it.
It was added between 2.6.24 and 2.6.25. Here's the commit message:
|commit ec5b1157f8e819c72fc93aa6d2d5117c08cdc961
|Author: Joe Peterson <address@hidden>
|Date: Wed Feb 6 01:37:38 2008 -0800
|
| tty: enable the echoing of ^C in the N_TTY discipline
|
| Turn on INTR/QUIT/SUSP echoing in the N_TTY line discipline (e.g. ctrl-C
| will appear as "^C" if stty echoctl is set and ctrl-C is set as INTR).
|
| Linux seems to be the only unix-like OS (recently I've verified this on
| Solaris, BSD, and Mac OS X) that does *not* behave this way, and I really
| miss this as a good visual confirmation of the interrupt of a program in
| the console or xterm. I remember this fondly from many Unixs I've used
| over the years as well. Bringing this to Linux also seems like a good way
| to make it yet more compliant with standard unix-like behavior.
|
| address@hidden: coding-style fixes]
| Cc: Alan Cox <address@hidden>
| Signed-off-by: Andrew Morton <address@hidden>
| Signed-off-by: Linus Torvalds <address@hidden>
And here's what I use to kill it (committed to my own git tree which is
exported to no one and has been seen by nobody but me until now):
commit 0b76f0a49a52ac37fb220f1481955426b6814f86
Author: Alan Curry <address@hidden>
Date: Wed Sep 22 16:35:01 2010 -0500
The echoing of ^C when a process is interrupted from tty may be more like
what the real unixes do, but this is a case where Linux was better. Put it
back the way it was.
When a command's output ends with an incomplete line, the shell can do one
of two things, both of them bad: engage its command line editor with the
cursor in the wrong column, or force the cursor to the first column before
printing the prompt, which obliterates the incomplete line, hiding actual
program output.
The echo of ^C immediately followed by process death is an instance of this
generally bad "command output ends with incomplete line" behavior.
diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
index c3954fb..70f5698 100644
--- a/drivers/tty/n_tty.c
+++ b/drivers/tty/n_tty.c
@@ -1194,10 +1194,12 @@ send_signal:
}
if (I_IXON(tty))
start_tty(tty);
+#if 0 /* This echoing is a sucky new feature. --Pac. */
if (L_ECHO(tty)) {
echo_char(c, tty);
process_echoes(tty);
}
+#endif
if (tty->pgrp)
kill_pgrp(tty->pgrp, signal, 1);
return;
--
Alan Curry