up-arrow no longer works right

up-arrow no longer works right

[TjL]

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

Re: up-arrow no longer works right

[Mikael Magnusson]

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

Re: up-arrow no longer works right

[Phil Pennock]

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

Re: up-arrow no longer works right

[TjL]

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

Re: up-arrow no longer works right

[Phil Pennock]

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.

Re: up-arrow no longer works right

[Vincent Lefevre]

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)

Re: up-arrow no longer works right

[Bart Schaefer]

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.

Re: up-arrow no longer works right

[Vincent Lefevre]

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)

Re: up-arrow no longer works right

[Andrey Borzenkov]

[-- 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 --]

Re: up-arrow no longer works right

[Peter Stephenson]

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/

Re: up-arrow no longer works right

[Vincent Lefevre]

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)

Re: up-arrow no longer works right

[Vincent Lefevre]

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)