* up-arrow no longer works right @ 2009-03-20 1:38 TjL 2009-03-20 1:41 ` Mikael Magnusson 2009-03-20 2:48 ` Phil Pennock 0 siblings, 2 replies; 12+ messages in thread From: TjL @ 2009-03-20 1:38 UTC (permalink / raw) To: Zsh Users List I thought I had asked this already, but I don't see it anywhere, so maybe I just imagined it. I have Zsh setup so that if I start typing and then press the up-arrow, it will go through the history and show me only those history commands that match what I have already typed. (I'm going to assume you all know what I'm talking about at this point. If it's not clear, let me know). The oddity is that sometimes (usually after exiting from ssh and/or screen) zsh seems to "forget" that, and pressing the up-arrow will just go back through my history line by line, ignoring what I have already typed. Usually at that point I just exit the shell and open a new one, but I'd really like to be able to kick-start my existing session if possible (especially when I've ssh'd somewhere). Any ideas what might cause this and (more importantly) what I can do to fix it? TjL ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: up-arrow no longer works right 2009-03-20 1:38 up-arrow no longer works right TjL @ 2009-03-20 1:41 ` Mikael Magnusson 2009-03-20 2:48 ` Phil Pennock 1 sibling, 0 replies; 12+ messages in thread From: Mikael Magnusson @ 2009-03-20 1:41 UTC (permalink / raw) To: Zsh Users List 2009/3/20 TjL <luomat@gmail.com>: > I thought I had asked this already, but I don't see it anywhere, so > maybe I just imagined it. > > I have Zsh setup so that if I start typing and then press the > up-arrow, it will go through the history and show me only those > history commands that match what I have already typed. > > (I'm going to assume you all know what I'm talking about at this > point. If it's not clear, let me know). > > The oddity is that sometimes (usually after exiting from ssh and/or > screen) zsh seems to "forget" that, and pressing the up-arrow will > just go back through my history line by line, ignoring what I have > already typed. > > Usually at that point I just exit the shell and open a new one, but > I'd really like to be able to kick-start my existing session if > possible (especially when I've ssh'd somewhere). I don't know what the actual problem is, but in the meantime, rather than exiting and re-logging in, just run 'exec zsh'. -- Mikael Magnusson ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: up-arrow no longer works right 2009-03-20 1:38 up-arrow no longer works right TjL 2009-03-20 1:41 ` Mikael Magnusson @ 2009-03-20 2:48 ` Phil Pennock 2009-03-20 6:03 ` TjL 1 sibling, 1 reply; 12+ messages in thread From: Phil Pennock @ 2009-03-20 2:48 UTC (permalink / raw) To: TjL; +Cc: Zsh Users List On 2009-03-19 at 21:38 -0400, TjL wrote: > The oddity is that sometimes (usually after exiting from ssh and/or > screen) zsh seems to "forget" that, and pressing the up-arrow will > just go back through my history line by line, ignoring what I have > already typed. > > Usually at that point I just exit the shell and open a new one, but > I'd really like to be able to kick-start my existing session if > possible (especially when I've ssh'd somewhere). > > Any ideas what might cause this and (more importantly) what I can do to fix it? Perhaps the cursor keys have been put into application mode and your terminal type isn't supporting them in that mode? When things are working, if you run: print -n '\e[?1h' do they stop working? If you run "bindkey", you'll see two batches for the two sets of cursor keys; for me: "^[OA" up-line-or-history "^[OB" down-line-or-history "^[OC" forward-char "^[OD" backward-char [...] "^[[A" up-line-or-history "^[[B" down-line-or-history "^[[C" forward-char "^[[D" backward-char If those two sets ^[O<foo> and ^[[<foo> differ then this might explain it. So, (1) bind both sets the same and (2) see if "stty sane" helps. And: print -n '\e[?1l' Regards, -Phil ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: up-arrow no longer works right 2009-03-20 2:48 ` Phil Pennock @ 2009-03-20 6:03 ` TjL 2009-03-20 7:15 ` Phil Pennock 0 siblings, 1 reply; 12+ messages in thread From: TjL @ 2009-03-20 6:03 UTC (permalink / raw) To: TjL, Zsh Users List On Thu, Mar 19, 2009 at 10:48 PM, Phil Pennock <zsh-workers+phil.pennock@spodhuis.org> wrote: > On 2009-03-19 at 21:38 -0400, TjL wrote: >> The oddity is that sometimes (usually after exiting from ssh and/or >> screen) zsh seems to "forget" that, and pressing the up-arrow will >> just go back through my history line by line, ignoring what I have >> already typed. >> >> Usually at that point I just exit the shell and open a new one, but >> I'd really like to be able to kick-start my existing session if >> possible (especially when I've ssh'd somewhere). >> >> Any ideas what might cause this and (more importantly) what I can do to fix it? > > Perhaps the cursor keys have been put into application mode and your > terminal type isn't supporting them in that mode? I don't know what that means :-/ > > When things are working, if you run: > print -n '\e[?1h' > do they stop working? yes > If you run "bindkey", you'll see two batches for the two sets of cursor > keys; for me: > "^[OA" up-line-or-history > "^[OB" down-line-or-history > "^[OC" forward-char > "^[OD" backward-char > [...] > "^[[A" up-line-or-history > "^[[B" down-line-or-history > "^[[C" forward-char > "^[[D" backward-char > > If those two sets ^[O<foo> and ^[[<foo> differ then this might explain > it. So, (1) bind both sets the same and (2) see if "stty sane" helps. 'stty sane' did not fix it > And: print -n '\e[?1l' that fixes it TjL ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: up-arrow no longer works right 2009-03-20 6:03 ` TjL @ 2009-03-20 7:15 ` Phil Pennock 2009-03-20 13:37 ` Vincent Lefevre 0 siblings, 1 reply; 12+ messages in thread From: Phil Pennock @ 2009-03-20 7:15 UTC (permalink / raw) To: TjL; +Cc: Zsh Users List On 2009-03-20 at 02:03 -0400, TjL wrote: > On Thu, Mar 19, 2009 at 10:48 PM, Phil Pennock > <zsh-workers+phil.pennock@spodhuis.org> wrote: > > Perhaps the cursor keys have been put into application mode and your > > terminal type isn't supporting them in that mode? > > I don't know what that means :-/ Any terminal emulator with a heritage that stretches back to emulating VT100 terminals will implement a certain set of features, with "standard" escape sequences for them. This includes xterm and all the knock-offs. One of these features is the ability to have the numeric keypad keys send different characters to the normal digits, etc. That's "application mode". The cursor keys can be put into a mode where they send escape sequences which are similar to the application mode escape sequences. That seems to be more common. I don't know enough about such things to know why any application bothers to do this. Normally, any program which changes the terminal mode will change it back against afterwards, but if the program did not shut down cleanly, or didn't get a chance to, then this won't happen. So, if you want the up-key to always invoke a particular widgit, then you need to bind *two* different escape sequences: both the normal \e[A and also \eOA (where the escape sequence ESC is in more modern environments written \e but in older setups is written ^[ instead). > > If you run "bindkey", you'll see two batches for the two sets of cursor > > keys; for me: > > "^[OA" up-line-or-history > > "^[OB" down-line-or-history > > "^[OC" forward-char > > "^[OD" backward-char > > [...] > > "^[[A" up-line-or-history > > "^[[B" down-line-or-history > > "^[[C" forward-char > > "^[[D" backward-char > > > > If those two sets ^[O<foo> and ^[[<foo> differ then this might explain > > it. So, (1) bind both sets the same and (2) see if "stty sane" helps. > > And: print -n '\e[?1l' > > that fixes it So, bind ^[OA as well as ^[[A and the keys will still work even in application mode. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: up-arrow no longer works right 2009-03-20 7:15 ` Phil Pennock @ 2009-03-20 13:37 ` Vincent Lefevre 2009-03-20 14:33 ` Bart Schaefer 0 siblings, 1 reply; 12+ messages in thread From: Vincent Lefevre @ 2009-03-20 13:37 UTC (permalink / raw) To: Zsh Users List; +Cc: TjL On 2009-03-20 00:15:57 -0700, Phil Pennock wrote: > So, if you want the up-key to always invoke a particular widgit, then > you need to bind *two* different escape sequences: both the normal \e[A > and also \eOA (where the escape sequence ESC is in more modern > environments written \e but in older setups is written ^[ instead). Alternatively, I think that something like [[ -n $TTY && -n $terminfo ]] && print -n "$terminfo[rmkx]" > $TTY in precmd() should work around this problem. Also, I've recently had a problem with the arrow keys after typing Ctrl-Z (to background a graphical application) and "bg": sometimes the escape sequences are output to the terminal, even though they are interpreted by zsh; typing [Enter] is sufficient to get the normal behavior back. For instance: vin:~> emacs file1 <14:28:38 ^Zzsh: suspended eclient file1 zsh: exit 20 vin:~[20]> bg <14:28:47 [1] + continued eclient file1 vin:~> <14:28:48 [1] + done eclient file1 vin:~> emacs file1 <14:28:51 ^Zzsh: suspended eclient file1 zsh: exit 20 vin:~[20]> bg <14:28:54 [1] + continued eclient file1 vin:~> ^[[A^[[A^[[A <14:28:55 bg bg: job already in background As you can see, there's no problem after the first bg. But after the second one, I get a ^[[A (in normal characters, so this is not like quote-insert, where ^[ appears in reverse video) for each up-arrow. When I hit [Enter], one can see that zsh recalled the first "bg" command from the history. This is with the zsh 4.3.9-3 Debian package. -- Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: up-arrow no longer works right 2009-03-20 13:37 ` Vincent Lefevre @ 2009-03-20 14:33 ` Bart Schaefer 2009-03-20 15:16 ` Vincent Lefevre 0 siblings, 1 reply; 12+ messages in thread From: Bart Schaefer @ 2009-03-20 14:33 UTC (permalink / raw) To: Zsh Users List On Mar 20, 2:37pm, Vincent Lefevre wrote: } } Also, I've recently had a problem with the arrow keys after typing } Ctrl-Z (to background a graphical application) and "bg": sometimes } the escape sequences are output to the terminal, even though they } are interpreted by zsh I'm not sure what you mean by "interpreted by zsh" but this is most likely a problem with something that's attempting to set the title bar string of the terminal. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: up-arrow no longer works right 2009-03-20 14:33 ` Bart Schaefer @ 2009-03-20 15:16 ` Vincent Lefevre 2009-03-20 17:52 ` Andrey Borzenkov 0 siblings, 1 reply; 12+ messages in thread From: Vincent Lefevre @ 2009-03-20 15:16 UTC (permalink / raw) To: Zsh Users List On 2009-03-20 07:33:26 -0700, Bart Schaefer wrote: > I'm not sure what you mean by "interpreted by zsh" but this is most > likely a problem with something that's attempting to set the title > bar string of the terminal. This can be reproduced with "zsh -f", and zsh doesn't attempt to change the terminal title. But one may need to use a machine with several processors, so that the race condition can be reproduced (mine has 2 processors). I've looked at strace output and I think I understand what happens: a SIGCHLD interrupts an ioctl system call, which leaves the terminal in an incorrect state. I did: vin:~> strace -t -o strace.out zsh -f vin% emacs file1 ^Z zsh: suspended emacs file1 vin% bg [1] + continued emacs file1 vin% ^[[A^[[A^[[A^[[A^[[B^[[B^[[D^[[C^[[D^[[A^[[B^[[B^[[B^[[B^[[B^[[B^[[A^[[A^[[A^[[A You can see what I get when typing the arrow keys. Here's an excerpt of the strace output: [...] 15:29:04 read(10, "b", 1) = 1 15:29:05 write(10, "b", 1) = 1 15:29:05 read(10, "g", 1) = 1 15:29:05 write(10, "\10bg", 3) = 3 15:29:05 read(10, "\n", 1) = 1 15:29:05 write(10, "\r\n", 2) = 2 15:29:05 alarm(0) = 0 15:29:05 ioctl(10, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig -icanon -echo ...}) = 0 15:29:05 ioctl(10, SNDCTL_TMR_STOP or TCSETSW, {B38400 opost isig icanon echo ...}) = 0 15:29:05 ioctl(10, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 15:29:05 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 15:29:05 write(10, "[1] + continued emacs file1\n", 30) = 30 15:29:05 kill(4294946362, SIGCONT) = 0 15:29:05 rt_sigprocmask(SIG_BLOCK, [CHLD], [CHLD], 8) = 0 15:29:05 rt_sigprocmask(SIG_UNBLOCK, [CHLD], [CHLD], 8) = 0 15:29:05 ioctl(10, TIOCSPGRP, [20933]) = 0 15:29:05 fstat(0, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 15), ...}) = 0 15:29:05 fcntl(0, F_GETFL) = 0x8002 (flags O_RDWR|O_LARGEFILE) 15:29:05 geteuid() = 1114 15:29:05 capget(0x20080522, 0, NULL) = -1 EFAULT (Bad address) 15:29:05 capget(0x20080522, 0, {0, 0, 0}) = 0 15:29:05 rt_sigaction(SIGINT, {0x474db0, [], SA_RESTORER|SA_INTERRUPT, 0x7f49a6593190}, NULL, 8) = 0 15:29:05 write(10, "\33[1m\33[7m%\33[27m\33[1m\33[m "..., 101) = 101 15:29:05 rt_sigaction(SIGINT, {0x474db0, [], SA_RESTORER|SA_INTERRUPT, 0x7f49a6593190}, NULL, 8) = 0 15:29:05 geteuid() = 1114 15:29:05 capget(0x20080522, 0, NULL) = -1 EFAULT (Bad address) 15:29:05 capget(0x20080522, 0, {0, 0, 0}) = 0 15:29:05 ioctl(10, FIONREAD, [0]) = 0 15:29:05 ioctl(10, TIOCSPGRP, [20933]) = 0 15:29:05 ioctl(10, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 15:29:05 ioctl(10, SNDCTL_TMR_STOP or TCSETSW, {B38400 opost isig -icanon -echo ...}) = -1 EINTR (Interrupted system call) 15:29:05 --- SIGCHLD (Child exited) @ 0 (0) --- 15:29:05 rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], [CHLD], 8) = 0 15:29:05 rt_sigprocmask(SIG_SETMASK, [CHLD], ~[KILL STOP RTMIN RT_1], 8) = 0 15:29:05 wait4(4294967295, 0x7fffaf3a553c, WNOHANG|WSTOPPED, 0x7fffaf3a5310) = 0 15:29:05 rt_sigreturn(0xffffffff) = -1 EINTR (Interrupted system call) 15:29:05 write(10, "\r\33[m\33[27m\33[24m\33[Jvin% ", 22) = 22 [...] Here's the corresponding excerpt in a case where the bug doesn't occur: [...] 15:56:24 read(10, "b", 1) = 1 15:56:24 write(10, "b", 1) = 1 15:56:24 read(10, "g", 1) = 1 15:56:24 write(10, "\10bg", 3) = 3 15:56:24 read(10, "\n", 1) = 1 15:56:25 write(10, "\r\n", 2) = 2 15:56:25 alarm(0) = 0 15:56:25 ioctl(10, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig -icanon -echo ...}) = 0 15:56:25 ioctl(10, SNDCTL_TMR_STOP or TCSETSW, {B38400 opost isig icanon echo ...}) = 0 15:56:25 ioctl(10, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 15:56:25 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 15:56:25 write(10, "[1] + continued emacs file1\n", 30) = 30 15:56:25 kill(4294942461, SIGCONT) = 0 15:56:25 rt_sigprocmask(SIG_BLOCK, [CHLD], [CHLD], 8) = 0 15:56:25 rt_sigprocmask(SIG_UNBLOCK, [CHLD], [CHLD], 8) = 0 15:56:25 --- SIGCHLD (Child exited) @ 0 (0) --- 15:56:25 rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], [CHLD], 8) = 0 15:56:25 rt_sigprocmask(SIG_SETMASK, [CHLD], ~[KILL STOP RTMIN RT_1], 8) = 0 15:56:25 wait4(4294967295, 0x7fff6946271c, WNOHANG|WSTOPPED, 0x7fff694624f0) = 0 15:56:25 rt_sigreturn(0xffffffff) = 0 15:56:25 ioctl(10, TIOCSPGRP, [24834]) = 0 15:56:25 fstat(0, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 7), ...}) = 0 15:56:25 fcntl(0, F_GETFL) = 0x8002 (flags O_RDWR|O_LARGEFILE) 15:56:25 geteuid() = 1114 15:56:25 capget(0x20080522, 0, NULL) = -1 EFAULT (Bad address) 15:56:25 capget(0x20080522, 0, {0, 0, 0}) = 0 15:56:25 rt_sigaction(SIGINT, {0x474db0, [], SA_RESTORER|SA_INTERRUPT, 0x7fb060650190}, NULL, 8) = 0 15:56:25 write(10, "\33[1m\33[7m%\33[27m\33[1m\33[m "..., 101) = 101 15:56:25 rt_sigaction(SIGINT, {0x474db0, [], SA_RESTORER|SA_INTERRUPT, 0x7fb060650190}, NULL, 8) = 0 15:56:25 geteuid() = 1114 15:56:25 capget(0x20080522, 0, NULL) = -1 EFAULT (Bad address) 15:56:25 capget(0x20080522, 0, {0, 0, 0}) = 0 15:56:25 ioctl(10, FIONREAD, [0]) = 0 15:56:25 ioctl(10, TIOCSPGRP, [24834]) = 0 15:56:25 ioctl(10, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 15:56:25 ioctl(10, SNDCTL_TMR_STOP or TCSETSW, {B38400 opost isig -icanon -echo ...}) = 0 15:56:25 ioctl(10, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig -icanon -echo ...}) = 0 15:56:25 write(10, "\r\33[m\33[27m\33[24m\33[Jvin% ", 22) = 22 [...] -- Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: up-arrow no longer works right 2009-03-20 15:16 ` Vincent Lefevre @ 2009-03-20 17:52 ` Andrey Borzenkov 2009-03-20 20:31 ` Peter Stephenson 0 siblings, 1 reply; 12+ messages in thread From: Andrey Borzenkov @ 2009-03-20 17:52 UTC (permalink / raw) To: Zsh Users List [-- Attachment #1: Type: text/plain, Size: 1468 bytes --] On 20 марта 2009 18:16:17 Vincent Lefevre wrote: > 15:29:05 ioctl(10, FIONREAD, [0]) = 0 > 15:29:05 ioctl(10, TIOCSPGRP, [20933]) = 0 > 15:29:05 ioctl(10, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig > icanon echo ...}) = 0 15:29:05 ioctl(10, SNDCTL_TMR_STOP or TCSETSW, > {B38400 opost isig -icanon -echo ...}) = -1 EINTR (Interrupted system > call) 15:29:05 --- SIGCHLD (Child exited) @ 0 (0) --- > 15:29:05 rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], [CHLD], 8) = 0 > 15:29:05 rt_sigprocmask(SIG_SETMASK, [CHLD], ~[KILL STOP RTMIN RT_1], > 8) = 0 15:29:05 wait4(4294967295, 0x7fffaf3a553c, WNOHANG|WSTOPPED, > 0x7fffaf3a5310) = 0 15:29:05 rt_sigreturn(0xffffffff) = -1 > EINTR (Interrupted system call) 15:29:05 write(10, > "\r\33[m\33[27m\33[24m\33[Jvin% ", 22) = 22 [...] > Actually zsh explicitly contains code to retry failed system call: # ifdef HAVE_TCGETATTR # ifndef TCSADRAIN # define TCSADRAIN 1 /* XXX Princeton's include files are screwed up */ # endif tcsetattr(SHTTY, TCSADRAIN, &ti->tio); while (tcsetattr(SHTTY, TCSADRAIN, &ti->tio) == -1 && errno == EINTR) ; # else ioctl(SHTTY, TCSETS, &ti->tio); while (ioctl(SHTTY, TCSETS, &ti->tio) == -1 && errno == EINTR) # endif /* zerr("settyinfo: %e",errno)*/ ; (looks like somewhat misplaced `;' but this should not be the reason). May be it interacts with signal handling somehow. [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 197 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: up-arrow no longer works right 2009-03-20 17:52 ` Andrey Borzenkov @ 2009-03-20 20:31 ` Peter Stephenson 2009-03-22 1:27 ` Vincent Lefevre 2009-03-25 13:05 ` Vincent Lefevre 0 siblings, 2 replies; 12+ messages in thread From: Peter Stephenson @ 2009-03-20 20:31 UTC (permalink / raw) To: Zsh Users List On Fri, 20 Mar 2009 20:52:12 +0300 Andrey Borzenkov <arvidjaar@gmail.com> wrote: > Actually zsh explicitly contains code to retry failed system call: > > # ifdef HAVE_TCGETATTR > # ifndef TCSADRAIN > # define TCSADRAIN 1 /* XXX Princeton's include files are screwed up > */ > # endif > tcsetattr(SHTTY, TCSADRAIN, &ti->tio); > while (tcsetattr(SHTTY, TCSADRAIN, &ti->tio) == -1 && errno == > EINTR) > ; > # else > ioctl(SHTTY, TCSETS, &ti->tio); > while (ioctl(SHTTY, TCSETS, &ti->tio) == -1 && errno == EINTR) > # endif > /* zerr("settyinfo: %e",errno)*/ ; > > (looks like somewhat misplaced `;' but this should not be the reason). This was a fairly recent change, however. I'm not sure why the tcsettattr() occurs twice, now I look again, but it's not occurring twice in Vincent's trace, as it would with the new code. Older code would print the message "bad tcgets", though. 2009-03-02 Peter Stephenson <pws@csr.com> * Lionel Flandrin: 26625: Src/utils.c: inopportune interrupt could wreck terminal set up. Index: Src/utils.c =================================================================== RCS file: /cvsroot/zsh/zsh/Src/utils.c,v retrieving revision 1.214 diff -u -r1.214 utils.c --- Src/utils.c 15 Mar 2009 01:04:51 -0000 1.214 +++ Src/utils.c 20 Mar 2009 20:27:57 -0000 @@ -1442,14 +1442,13 @@ # ifndef TCSADRAIN # define TCSADRAIN 1 /* XXX Princeton's include files are screwed up */ # endif - tcsetattr(SHTTY, TCSADRAIN, &ti->tio); while (tcsetattr(SHTTY, TCSADRAIN, &ti->tio) == -1 && errno == EINTR) ; # else - ioctl(SHTTY, TCSETS, &ti->tio); while (ioctl(SHTTY, TCSETS, &ti->tio) == -1 && errno == EINTR) + ; # endif - /* zerr("settyinfo: %e",errno)*/ ; + /* zerr("settyinfo: %e",errno);*/ #else # ifdef HAVE_TERMIO_H ioctl(SHTTY, TCSETA, &ti->tio); -- Peter Stephenson <p.w.stephenson@ntlworld.com> Web page now at http://homepage.ntlworld.com/p.w.stephenson/ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: up-arrow no longer works right 2009-03-20 20:31 ` Peter Stephenson @ 2009-03-22 1:27 ` Vincent Lefevre 2009-03-25 13:05 ` Vincent Lefevre 1 sibling, 0 replies; 12+ messages in thread From: Vincent Lefevre @ 2009-03-22 1:27 UTC (permalink / raw) To: Zsh Users List On 2009-03-20 20:31:23 +0000, Peter Stephenson wrote: > This was a fairly recent change, however. I'm not sure why the > tcsettattr() occurs twice, now I look again, but it's not occurring > twice in Vincent's trace, as it would with the new code. Older code > would print the message "bad tcgets", though. > > 2009-03-02 Peter Stephenson <pws@csr.com> > > * Lionel Flandrin: 26625: Src/utils.c: inopportune interrupt > could wreck terminal set up. [...] I'll try on Monday (I don't have physical access to the machine here). -- Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: up-arrow no longer works right 2009-03-20 20:31 ` Peter Stephenson 2009-03-22 1:27 ` Vincent Lefevre @ 2009-03-25 13:05 ` Vincent Lefevre 1 sibling, 0 replies; 12+ messages in thread From: Vincent Lefevre @ 2009-03-25 13:05 UTC (permalink / raw) To: Zsh Users List On 2009-03-20 20:31:23 +0000, Peter Stephenson wrote: > This was a fairly recent change, however. I'm not sure why the > tcsettattr() occurs twice, now I look again, but it's not occurring > twice in Vincent's trace, as it would with the new code. Older code > would print the message "bad tcgets", though. > > 2009-03-02 Peter Stephenson <pws@csr.com> > > * Lionel Flandrin: 26625: Src/utils.c: inopportune interrupt > could wreck terminal set up. Thanks, this seems to fix the problem. Here's the patch modified for zsh 4.3.9: --- Src/utils.c.orig 2008-10-31 10:40:18.000000000 +0100 +++ Src/utils.c 2009-03-25 13:55:54.000000000 +0100 @@ -1437,13 +1437,13 @@ # ifndef TCSADRAIN # define TCSADRAIN 1 /* XXX Princeton's include files are screwed up */ # endif - tcsetattr(SHTTY, TCSADRAIN, &ti->tio); - /* if (tcsetattr(SHTTY, TCSADRAIN, &ti->tio) == -1) */ + while (tcsetattr(SHTTY, TCSADRAIN, &ti->tio) == -1 && errno == EINTR) + ; # else - ioctl(SHTTY, TCSETS, &ti->tio); - /* if (ioctl(SHTTY, TCSETS, &ti->tio) == -1) */ + while (ioctl(SHTTY, TCSETS, &ti->tio) == -1 && errno == EINTR) + ; # endif - /* zerr("settyinfo: %e",errno)*/ ; + /* zerr("settyinfo: %e",errno);*/ #else # ifdef HAVE_TERMIO_H ioctl(SHTTY, TCSETA, &ti->tio); -- Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2009-03-25 13:06 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-03-20 1:38 up-arrow no longer works right TjL 2009-03-20 1:41 ` Mikael Magnusson 2009-03-20 2:48 ` Phil Pennock 2009-03-20 6:03 ` TjL 2009-03-20 7:15 ` Phil Pennock 2009-03-20 13:37 ` Vincent Lefevre 2009-03-20 14:33 ` Bart Schaefer 2009-03-20 15:16 ` Vincent Lefevre 2009-03-20 17:52 ` Andrey Borzenkov 2009-03-20 20:31 ` Peter Stephenson 2009-03-22 1:27 ` Vincent Lefevre 2009-03-25 13:05 ` Vincent Lefevre
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).