* zsh, ctrl-something, and recent kernels @ 2006-02-04 22:00 Nathan Grennan 2006-02-05 11:44 ` Brian K. White 0 siblings, 1 reply; 4+ messages in thread From: Nathan Grennan @ 2006-02-04 22:00 UTC (permalink / raw) To: zsh-users I have a problem with zsh and recent kernels when I try to use ctrl-c or ctrl-z. It seems to have started after 2.6.16-rc1-git4. I can currently see it in 2.6.16rc2. I started with zsh-4.2.5 and I have tried 4.2.6 too. I sort of tried 4.3.0 cvs, and it didn't seem to work either. But since I couldn't get it packaged, and had errors with it, I am not sure with it. The behavior seems to have changed with the recently kernel releases. When I first noticed it I could ctrl-c repeatedly until I ran ls | less and then quit out. Now if I just try to ctrl-c a second time at the prompt ctrl-c stops working. If I go back to 2.6.16-rc1-git4 or older it works every time. I suspect it is a bug or bugs in signals.c. I originally thought it was a kernel bug, in that if I ran bash from zsh I had the same problem. Today I tried bash directly and it works on the latest kernel releases. It still could be a bug in the kernel, but I suspect it is just a change in behavior of the kernel and zsh needs to deal with it. The url for my bug report to Red Hat is below. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178882 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: zsh, ctrl-something, and recent kernels 2006-02-04 22:00 zsh, ctrl-something, and recent kernels Nathan Grennan @ 2006-02-05 11:44 ` Brian K. White 2006-02-05 17:39 ` Nathan Grennan 0 siblings, 1 reply; 4+ messages in thread From: Brian K. White @ 2006-02-05 11:44 UTC (permalink / raw) To: zsh-users ----- Original Message ----- From: "Nathan Grennan" <zsh-users@cygnusx-1.org> To: <zsh-users@sunsite.dk> Sent: Saturday, February 04, 2006 5:00 PM Subject: zsh, ctrl-something, and recent kernels > I have a problem with zsh and recent kernels when I try to use ctrl-c or > ctrl-z. It seems to have started after 2.6.16-rc1-git4. I can currently > see it in 2.6.16rc2. I started with zsh-4.2.5 and I have tried 4.2.6 too. > I sort of tried 4.3.0 cvs, and it didn't seem to work either. But since I > couldn't get it packaged, and had errors with it, I am not sure with it. > > The behavior seems to have changed with the recently kernel releases. > When I first noticed > it I could ctrl-c repeatedly until I ran ls | less and then quit out. Now > if I just try to ctrl-c a second time at the prompt ctrl-c stops working. > If I go back to 2.6.16-rc1-git4 or older it works every time. I suspect it > is a bug or bugs in signals.c. > > I originally thought it was a kernel bug, in that if I ran bash from zsh > I had the same problem. Today I tried bash directly and it works on the > latest kernel releases. It still could be a bug in the kernel, but I > suspect it is just a change in behavior of the kernel and zsh needs to > deal with it. The url for my bug report to Red Hat is below. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178882 First off, "recent kernels" is meaningless. I have very recent FreeBSD and SCO Open Server kernels that do not display any such problem with any version of zsh. Secondly, "ctrl-c" is likewise meaningless, at least until we establish that the kernel in question must be Linux, and that you haven't used stty to change the interrupt key from it'sdefault. Thirdly, unlike the 2 points above which can be deduced because eventually at the end you mentioned RedHat, another important fact can't be deduced, which is what kind of terminal (or trail of terminals) is this failure appearing on? The console? xterm? rxvt/gnometerm/other xterm-alike? one of the bezillion windows terminal emulators? and the communication layer? ssh? telnet? rlogin? serial? local socket? X over tcp-ip? Vnc? Several of the above thus eliminating any one as the culprit? Using all three of putty over ssh, the console, and rxvt, on all three of freebsd, sco open server, and suse 10.0 (linux 2.6.13 smp kernel) (9 different tests), I do not see a problem with the break key (no mater what I set "intr" to, including ctrl-c) So, it sounds like a tty driver bug in recent linux kernels to me, not anything even within zsh's possibility to control or work around, let alone be obligatd to. It's the terminals job to read the physical keyboard and keep track of such things as the state of the various mode shifting meta keys and translate some actions into other things. It's the tty drivers job to recognize and interpret some sequences and translate them into other things or otherwise act upon them, while still being considered input. It's the kernels job or the server side communication daemon (sshd, telnetd, etc...) 's job to send signals to the child processes like zsh. zsh merely has to trap the signal, which if it does on any platform then it's doing it. If a recent linux kernel changed to cause this, then that kernel changed away from doing the right thing to doing the wrong thing and it's the kernel that needs to change back. Try setting intr to a plain single character like ~, or one that doesn't need any meta keys, not even the shift key, like . or , or ' or ` (obviously once you do that you have to be careful to avoid commands that need the character you chose) and use cat -v (why I didn't suggest - as a new break key) and see what happens when you press ctrl-c [enter] once, twice, three times. You should see ^C for each time you press ctrl-c, but you don't see anything until you press Enter, then you see everything that happenes since the last Enter. (or ctrl-m for that matter!) You could use ctrl-v followed by ctrl-c right on the zsh command line, but it's stupid to try and use a ctrl key it to diagnose a problem that might be with ctrl keys in general. Maybe ctrl-v also only works once. Or maybe ctrl-anything, such that the ctrl-v would work, and then the immediately following ctrl-c doesn't. The stty change only lives for the duration of that session and only effects that session, it's completely safe. If you don't see ^C the 2nd or 3rd times, then something is wrong way before zsh can do anything about it. If you do see a ^C for every time you press it then it's a little more interesting. In that case, start a new session without running stty, press ctrl-c until it stops working, then run stty intr "^c", and then press ctrl-c again. Does the stty reset the ctrl-c so that it works one more time? Start another new session and run "stty -a >stty.a" Then press ctrl-c until it stops working Then run stty -a >stty.b Then diff -u stty.a stty.b Do stty.a and stty.b differ at all? Do the same test under bash and ksh. (if ctrl-c never stops working n bash or ksh, then just press it however many times it takes for it to stop working in zsh.) Do stty.a & .b differ under zsh but not under other shells? Try running bash from within bash. Does ctrl-c fail in the child bash but not in the parent? Try running bash as a child under zsh. Does the child-of-zsh-bash still work? Try setting a users login shell to zsh (as opposed to running zsh manually after logging in to a login shell of bash). Does ctrl-c still fail then? Try other shells besides just bash & zsh. try ksh (or pdksh) ash, csh etc... There may be a quirk where something is wrong but just bash happens to work anyway. Like maybe the wrong signal is being sent after the first time, but maybe bash just happens to trap that other signal too, and just happens to treat it similarly to break (ctrl-c). For that matter, you could do this: n=0 ;until [ $n -gt 15 ] ;do trap "echo $n" $n ;((n++)) ;done Then press ctrl-c a few times. On a properly working terminal you should see "2" every time you press "break" ie ctrl-c in your case. If you stop getting new 2's, or start getting something else, then the os or possibly the server communication daemon is broken. Try the same thing in bash. ksh. Try the same thing under different server daemons (ie: telnet, rlogin, directly at the console, an xterm window, etc.. instead of opensshd) Brian, who is annoyed by people who forget that the universe is not linux. At least by using zsh you automatically avoid the similar annoyance of people who think all "sh" everywhere is bash and write scripts accordingly. Brian K. White -- brian@aljex.com -- http://www.aljex.com/bkw/ +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++. filePro BBx Linux SCO FreeBSD #callahans Satriani Filk! ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: zsh, ctrl-something, and recent kernels 2006-02-05 11:44 ` Brian K. White @ 2006-02-05 17:39 ` Nathan Grennan 2006-02-05 19:16 ` Brian K. White 0 siblings, 1 reply; 4+ messages in thread From: Nathan Grennan @ 2006-02-05 17:39 UTC (permalink / raw) To: zsh-users Brian K. White wrote: > First off, "recent kernels" is meaningless. Meaningless no, no specify at this point in the message, yes. > I have very recent FreeBSD and SCO Open Server kernels that do not > display any such problem with any version of zsh. Ok, that is useful information. > > Secondly, "ctrl-c" is likewise meaningless, at least until we > establish that the kernel in question must be Linux, and that you > haven't used stty to change the interrupt key from it'sdefault. I disagree that ctrl-c is meaningless. Plus as the topic and the beginning of the message suggest, I have problems with more than just ctrl-c. I do mention ctrl-z in the original message. I just use ctrl-c as my example, since it was the one I ran into first, and is the most commonly used. > Thirdly, unlike the 2 points above which can be deduced because > eventually at the end you mentioned RedHat, another important fact > can't be deduced, which is what kind of terminal (or trail of > terminals) is this failure appearing on? The console? xterm? > rxvt/gnometerm/other xterm-alike? one of the bezillion windows > terminal emulators? and the communication layer? ssh? telnet? rlogin? > serial? local socket? X over tcp-ip? Vnc? Several of the above thus > eliminating any one as the culprit? > Before the end I do mention versions of the Linux kernel that are very likely only Linux kernel versions and not any other OS's kernel versions. If you had read the bug report I linked to, you would have found I mention the console, and more details. > Using all three of putty over ssh, the console, and rxvt, on all three > of freebsd, sco open server, and suse 10.0 (linux 2.6.13 smp kernel) > (9 different tests), I do not see a problem with the break key (no > mater what I set "intr" to, including ctrl-c) > Not surprised I have never seen it before with Linux, and I have been using zsh for years with it. > So, it sounds like a tty driver bug in recent linux kernels to me, not > anything even within zsh's possibility to control or work around, let > alone be obligatd to. > It's the terminals job to read the physical keyboard and keep track of > such things as the state of the various mode shifting meta keys and > translate some actions into other things. > It's the tty drivers job to recognize and interpret some sequences and > translate them into other things or otherwise act upon them, while > still being considered input. > It's the kernels job or the server side communication daemon (sshd, > telnetd, etc...) 's job to send signals to the child processes like zsh. > zsh merely has to trap the signal, which if it does on any platform > then it's doing it. If a recent linux kernel changed to cause this, > then that kernel changed away from doing the right thing to doing the > wrong thing and it's the kernel that needs to change back. > Maybe, but the goal is to figure out exactly why, and who should fix it. In my mind the evidence is pointing to zsh, hence why I asked on this mailing list. > Try setting intr to a plain single character like ~, or one that > doesn't need any meta keys, not even the shift key, like . or , or ' > or ` (obviously once you do that you have to be careful to avoid > commands that need the character you chose) and use cat -v (why I > didn't suggest - as a new break key) and see what happens when you > press ctrl-c [enter] once, twice, three times. You should see ^C for > each time you press ctrl-c, but you don't see anything until you press > Enter, then you see everything that happenes since the last Enter. (or > ctrl-m for that matter!) > You could use ctrl-v followed by ctrl-c right on the zsh command line, > but it's stupid to try and use a ctrl key it to diagnose a problem > that might be with ctrl keys in general. Maybe ctrl-v also only works > once. Or maybe ctrl-anything, such that the ctrl-v would work, and > then the immediately following ctrl-c doesn't. The stty change only > lives for the duration of that session and only effects that session, > it's completely safe. After setting intr to ~ it behaves as expected. I can run cat -v and see ^C over and over. I see the same if I change susp, ^Z, to ~. > If you don't see ^C the 2nd or 3rd times, then something is wrong way > before zsh can do anything about it. > If you do see a ^C for every time you press it then it's a little more > interesting. > In that case, start a new session without running stty, press ctrl-c > until it stops working, then run stty intr "^c", and then press ctrl-c > again. Does the stty reset the ctrl-c so that it works one more time? > I do see ^C the 2nd and 2rd times. Using stty intr "^c" doesn't help. It is already set to ^c, and it just stays the same. > Start another new session and run "stty -a >stty.a" > Then press ctrl-c until it stops working > Then run stty -a >stty.b > Then diff -u stty.a stty.b > Do stty.a and stty.b differ at all? > No difference > Do the same test under bash and ksh. (if ctrl-c never stops working n > bash or ksh, then just press it however many times it takes for it to > stop working in zsh.) > Do stty.a & .b differ under zsh but not under other shells? > > Try running bash from within bash. Does ctrl-c fail in the child bash > but not in the parent? > Try running bash as a child under zsh. Does the child-of-zsh-bash > still work? > Try setting a users login shell to zsh (as opposed to running zsh > manually after logging in to a login shell of bash). Does ctrl-c still > fail then? > Try other shells besides just bash & zsh. try ksh (or pdksh) ash, csh > etc... There may be a quirk where something is wrong but just bash > happens to work anyway. Like maybe the wrong signal is being sent > after the first time, but maybe bash just happens to trap that other > signal too, and just happens to treat it similarly to break (ctrl-c). > I didn't try bash in bash. But bash directly works perfectly, zsh obviously doesn't, bash in zsh before the problem occurs in zsh works, and bash in zsh after the problems appears in zsh doesn't work. > For that matter, you could do this: > n=0 ;until [ $n -gt 15 ] ;do trap "echo $n" $n ;((n++)) ;done > Then press ctrl-c a few times. > On a properly working terminal you should see "2" every time you press > "break" ie ctrl-c in your case. > If you stop getting new 2's, or start getting something else, then the > os or possibly the server communication daemon is broken. > Try the same thing in bash. ksh. > Try the same thing under different server daemons (ie: telnet, rlogin, > directly at the console, an xterm window, etc.. instead of opensshd) > In zsh the ctrl-c to print a 2 works until I run a command like ls. Then it stops printing 2s until I repeat the n=0... again. With bash it works even after running ls. I tried most of my testing on the console, as in tty1. I repeated some of the tests in a ssh connection from my laptop to the desktop with the problem using putty. I saw the exact same results I saw on the console. The ssh connection use a pts, like pts/8. I have also tried some of this in the past inside gnome-terminal with at least similar results, again a pts. I did test more than ctrl-c. ctrl-z doesn't work from what appears to be the start. I login, I run top, I try ctrl-z, and get nothing. In bash it works just fine. > Brian, who is annoyed by people who forget that the universe is not > linux. I didn't specify exactly, but I gave plenty of big hints I was talking only about Linux. But I understand your point. > At least by using zsh you automatically avoid the similar annoyance of > people who think all "sh" everywhere is bash and write scripts > accordingly. > I think it is bad that many don't know anything but bash exists. As for scripts, bash is at least virtually the universal Linux default shell, and there are too many shell differences to try to be shell agnostic with all scripts. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: zsh, ctrl-something, and recent kernels 2006-02-05 17:39 ` Nathan Grennan @ 2006-02-05 19:16 ` Brian K. White 0 siblings, 0 replies; 4+ messages in thread From: Brian K. White @ 2006-02-05 19:16 UTC (permalink / raw) To: zsh-users ----- Original Message ----- From: "Nathan Grennan" <zsh-users@cygnusx-1.org> To: <zsh-users@sunsite.dk> Sent: Sunday, February 05, 2006 12:39 PM Subject: Re: zsh, ctrl-something, and recent kernels >> n=0 ;until [ $n -gt 15 ] ;do trap "echo $n" $n ;((n++)) ;done >> Then press ctrl-c a few times. >> On a properly working terminal you should see "2" every time you press >> "break" ie ctrl-c in your case. >> If you stop getting new 2's, or start getting something else, then the >> os or possibly the server communication daemon is broken. > In zsh the ctrl-c to print a 2 works until I run a command like ls. Then > it stops printing 2s until I repeat the n=0... again. With bash it works > even after running ls. Now that is interesting ... Brian K. White -- brian@aljex.com -- http://www.aljex.com/bkw/ +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++. filePro BBx Linux SCO FreeBSD #callahans Satriani Filk! ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2006-02-05 19:17 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2006-02-04 22:00 zsh, ctrl-something, and recent kernels Nathan Grennan 2006-02-05 11:44 ` Brian K. White 2006-02-05 17:39 ` Nathan Grennan 2006-02-05 19:16 ` Brian K. White
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).