* 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).