为什么在Linux上使用RS-232时CTRL C不起作用？
|
首先,我不知道这应该留在SO还是去SU：你告诉我.解决方案可能与编程有关.
我在嵌入式设备上执行Linux并使用RS-232 @ 9600波特与它通信.在Windows上使用PuTTY一切正常：我有一个shell,可以输入和执行命令. 问题是：当我启动命令时,我无法按CTRL C.例如,当ping某个机器时,ping进入无限循环,我无法使用CTRL C停止它.但是在Bash提示符下,CTRL C工作正常转到下一行(因此它被传输).我还注意到,当我在运行命令时执行CTRL C时终端显示^ C.通过Telnet连接时,CTRL C可以在任何地方正常工作. 我尝试使用PuTTY的“特殊命令”中断,但它不起作用.我也试过不同的终端模拟器,同样的问题. 所以我猜这个问题与内核有关.有什么我可以考虑的吗？ 编辑：我正在运行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 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 我只是注意到,如果我执行ls -la / bin,这是一个很长的命令来执行,因为列表很长,我不能仅仅通过发出CTRL C来打破,但是我可以在保持按键关闭时.它在大约一秒后破裂.但是,这不适用于ping. 事实上,如果我执行seq 1 1000然后按CTRL C,它似乎在某个时刻一次跳过多行： 93 94 95 ^C6 897 898 899 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 解决方法
嵌入式设备上的串行端口设置可能忽略中断字符,或者在收到中断时不会导致中断.您可以通过从设备的shell(或启动脚本)运行stty程序,或使用各种ioctl()参数编写程序来更改此设置.
http://linux.die.net/man/1/stty stty sane 可能是最好的选择.这设置了一堆“通常”设置.相反,如果你这样做 stty raw 在桌面Linux的shell窗口中,您可能会在嵌入式设备上看到ctrl-C打印但没有任何行为. 不带参数运行stty可能会打印出当前设置,这可能很有趣 – 特别是比较串行和telnet会话的结果. 更新：在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
（编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |