为什么在 Linux 上使用 RS-232 时 CTRL+C 不起作用？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/10467687/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Why CTRL+C won't work when using RS-232 on Linux?
提问by eepp
First of all, I don't know if this should stay in SO or go to SU: you tell me. The solution might have to do with programming.
首先，我不知道这应该留在 SO 还是去 SU：你告诉我。解决方案可能与编程有关。
I am executing Linux on an embedded device and communicating with it using RS-232 @ 9600 bauds. Everything works fine using PuTTY on Windows: I have a shell and can type and execute commands.
我正在嵌入式设备上执行 Linux，并使用 RS-232 @ 9600 波特率与它通信。在 Windows 上使用 PuTTY 一切正常：我有一个 shell，可以输入和执行命令。
The problem is: when I launch a command, I cannot CTRL+C. For example, when pinging some machine, ping goes into an infinite loop and I cannot stop it using CTRL+C. When at the Bash prompt, though, CTRL+C works and goes to the next line (so it is transmitted). I also noticed the terminal is showing ^Cwhen I do CTRL+C while running a command. When connecting through Telnet, CTRL+C works fine anywhere.
问题是：当我启动一个命令时，我不能 CTRL+C。例如，ping 某台机器时，ping 进入无限循环，我无法使用 CTRL+C 停止它。但是，当在 Bash 提示符下时，CTRL+C 起作用并转到下一行（因此它被传输）。我还注意到^C当我在运行命令时按 CTRL+C 时显示终端。通过 Telnet 连接时，CTRL+C 在任何地方都可以正常工作。
I tried using PuTTY's "special command" break, but it doesn't work. I also tried different terminal emulators, same problem.
我尝试使用 PuTTY 的“特殊命令”中断，但它不起作用。我也试过不同的终端模拟器，同样的问题。
So I guess the problem is somehow kernel-related. Is there anything I could look into regarding this?
所以我猜这个问题在某种程度上与内核有关。有什么我可以调查的吗？
Edit: I am running BusyBox v1.13.2. The output of stty -a(RS-232) is:
编辑：我正在运行 BusyBox v1.13.2。stty -a(RS-232)的输出为：
speed 9600 baud; rows 24; columns 80;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W;
lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts
-ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon ixoff
-iuclc -ixany -imaxbel
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke
The output of stty -a(Telnet) is:
stty -a(Telnet)的输出是：
speed 38400 baud; rows 24; columns 80;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W;
lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab3 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke
I just noticed that if I do ls -la /bin, which is a long command to execute since the list is long, I cannot break by just issuing CTRL+C, but I can when keeping the keys down. It breaks after about one second. This doesn't work with ping, however.
我只是注意到，如果我这样做了ls -la /bin，这是一个很长的命令，因为列表很长，我不能通过发出 CTRL+C 来中断，但是当按住键时我可以。它在大约一秒钟后中断。但是，这不适用于 ping。
In fact, if I do seq 1 1000and then press CTRL+C, it seems like it skips many lines at one shot at some point:
事实上，如果我这样做seq 1 1000然后按 CTRL+C，它似乎在某个时刻一次跳过了很多行：
93
94
95
^C6
897
898
899
Same thing happens with ls -la /bin:
同样的事情发生在ls -la /bin：
lrwxrwxrwx 1 10042 2223 7 May 6 2012 dmesg -> busybox
lrwxrwxrwx 1 10042 2223 7 May 6 2012 dos2unix -> busybox
lrwxrwxrwx 1 10042 2223 7^C 7 May 6 2012 ipcrm -> busybox
lrwxrwxrwx 1 10042 2223 7 May 6 2012 ipcs -> busybox
lrwxrwxrwx 1 10042 2223 7 May 6 2012 iplink -> busybox
采纳答案by Chris Stratton
The serial port settings on the embedded device are likely either ignoring break characters, or not causing an interrupt on receipt of a break. You can change this by running the stty program from the device's shell (or startup scripts), or by writing a program using various ioctl() paramaters.
嵌入式设备上的串行端口设置可能会忽略中断字符，或者在接收到中断时不会引起中断。您可以通过从设备的 shell（或启动脚本）运行 stty 程序或使用各种 ioctl() 参数编写程序来更改此设置。
http://linux.die.net/man/1/stty
http://linux.die.net/man/1/stty
stty sane
Might be the best bet. This sets up a bunch of "usual" settings. In constrast, if you do
可能是最好的选择。这设置了一堆“通常”设置。相反，如果你这样做
stty raw
In a shell window of a desktop linux, you will likely get the kind of ctrl-C prints-but-does-nothing behavior you are seeing on your embedded device.
在桌面 linux 的 shell 窗口中，您可能会看到在嵌入式设备上看到的那种 ctrl-C 打印但不执行任何行为。
Running stty without arguments may print out the current settings, which could be interesting - especially comparing the result on the serial vs telnet sessions.
不带参数运行 stty 可能会打印出当前设置，这可能很有趣 - 特别是比较串行与 telnet 会话的结果。
Update: A web search on busybox and BRKINT found something likely relevant:
更新：在 busybox 和 BRKINT 上的网络搜索发现了一些可能相关的内容：
Date: Thu, 31 Jan 2002 13:34:34 -0800
From: Scott Anderson <scott_anderson at [removed]>
Cc: linuxppc-dev at lists.linuxppc.org
Subject: Re: why is tty->pgrp set to -1 for console?
> What is the correct procedure to follow to get around this problem
> and get ctrl-c working on console?
It looks like everyone is taking a swing at this one, so I think I'll
join in. First off, the easiest way I've found to track down why
ctrl-c doesn't work is to just run "ps -j". For ctrl-c to work, you
need a controlling terminal (the TTY column) and a process group. If
you have a '?' in the TTY column, ctrl-c won't work. In the past I
have seen this happen because of this code in drivers/char/tty_io.c:
if (device == SYSCONS_DEV) {
struct console *c = console_drivers;
while(c && !c->device)
c = c->next;
if (!c)
return -ENODEV;
device = c->device(c);
filp->f_flags |= O_NONBLOCK; /* Don't let /dev/console block */
noctty = 1;
}
Note that O_NOCTTY (no controlling terminal) is forced on whenever
/dev/console is opened (noctty = 1). Possible workarounds:
1) Run getty on something other than /dev/console. For example,
if you console is on the first serial port, run getty on /dev/ttyS0.
I believe this is the "correct" answer.
2) You could also change getty to do a TIOCSCTTY ioctl explicitly after
it has opened the terminal.
3) You could remove the forcing of noctty on from tty_io.c
回答by Paulo Neves
Very tangent, but as I could not find an objective command to type, out of desperation I did
ssh 127.0.0.1and ctrl-c worked inside the ssh session.
非常切中要害，但由于我找不到一个客观的命令来输入，出于绝望，我做了
ssh 127.0.0.1并且 ctrl-c 在 ssh 会话中工作。
