* strange behavior @ 2010-11-02 12:09 Vincent Lefevre 2010-11-15 16:32 ` Vincent Lefevre 0 siblings, 1 reply; 13+ messages in thread From: Vincent Lefevre @ 2010-11-02 12:09 UTC (permalink / raw) To: zsh-users With the svnwrapper script below, I got after rebooting the machine: ypig:~/wd> up At revision 40202. zsh: exit 141 ypig:~/wd[PIPE]> where "up" does "svnwrapper up". I don't see how this could be possible, as the only svn output is "At revision 40202." to stdout (nothing to stderr here, so that brpipe remains unset). svnwrapper script: #!/usr/bin/env zsh filter() { unset brpipe while true do unset line timeout while read -r $timeout -k -u 0 ch do line="$line$ch" [[ $ch = $'\012' ]] && break timeout=(-t 0.1) done case $line in svnwrapper:term$'\012') break ;; *Broken\ pipe$'\012') brpipe=1 ;; ?*) printf "%s" "$line" >&2 ;; *) break ;; # empty line (end of file) - parent has died? esac done # The "sleep 5" is there to avoid a rare race condition (it occurred # once): make sure the parent process receives the PIPE signal before # the filter process terminates (which can yield a SIGPIPE in svn). [[ -z $brpipe ]] || { kill -PIPE $$; sleep 5 } } { svn "$@"; st=$?; echo "svnwrapper:term" >&2 } 2>>(filter) exit $st -- Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon) ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: strange behavior 2010-11-02 12:09 strange behavior Vincent Lefevre @ 2010-11-15 16:32 ` Vincent Lefevre 2010-11-15 17:24 ` Bart Schaefer 0 siblings, 1 reply; 13+ messages in thread From: Vincent Lefevre @ 2010-11-15 16:32 UTC (permalink / raw) To: zsh-users On 2010-11-02 13:09:43 +0100, Vincent Lefevre wrote: > With the svnwrapper script below, I got after rebooting the machine: > > ypig:~/wd> up > At revision 40202. > zsh: exit 141 > ypig:~/wd[PIPE]> > > where "up" does "svnwrapper up". I don't see how this could be > possible, as the only svn output is "At revision 40202." to stdout > (nothing to stderr here, so that brpipe remains unset). [...] This has just happened again. This time, the machine hadn't been rebooted (but there has been a lot of disk activity before that). -- Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon) ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: strange behavior 2010-11-15 16:32 ` Vincent Lefevre @ 2010-11-15 17:24 ` Bart Schaefer 2010-11-16 3:10 ` Vincent Lefevre 0 siblings, 1 reply; 13+ messages in thread From: Bart Schaefer @ 2010-11-15 17:24 UTC (permalink / raw) To: zsh-users On Nov 15, 5:32pm, Vincent Lefevre wrote: } } > ypig:~/wd> up } > At revision 40202. } > zsh: exit 141 } > ypig:~/wd[PIPE]> } } This has just happened again. This time, the machine hadn't been } rebooted (but there has been a lot of disk activity before that). It appears to me that it must be the case that svn "$@" is exiting with status 141, rather than that the filter function is killing its parent with a PIPE signal. That in turn must be happening "inside" svn somewhere. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: strange behavior 2010-11-15 17:24 ` Bart Schaefer @ 2010-11-16 3:10 ` Vincent Lefevre 2011-01-28 14:44 ` Vincent Lefevre 0 siblings, 1 reply; 13+ messages in thread From: Vincent Lefevre @ 2010-11-16 3:10 UTC (permalink / raw) To: zsh-users On 2010-11-15 09:24:38 -0800, Bart Schaefer wrote: > On Nov 15, 5:32pm, Vincent Lefevre wrote: > } > } > ypig:~/wd> up > } > At revision 40202. > } > zsh: exit 141 > } > ypig:~/wd[PIPE]> > } > } This has just happened again. This time, the machine hadn't been > } rebooted (but there has been a lot of disk activity before that). > > It appears to me that it must be the case that > svn "$@" > is exiting with status 141, rather than that the filter function is > killing its parent with a PIPE signal. I don't think this is possible as when svn receives a PIPE signal, it outputs "svn: Write error: Broken pipe" and exits with status 1. But I've added some code to check that status 141 is not possible. -- Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon) ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: strange behavior 2010-11-16 3:10 ` Vincent Lefevre @ 2011-01-28 14:44 ` Vincent Lefevre 2011-01-28 15:49 ` Bart Schaefer 0 siblings, 1 reply; 13+ messages in thread From: Vincent Lefevre @ 2011-01-28 14:44 UTC (permalink / raw) To: zsh-users On 2010-11-16 04:10:23 +0100, Vincent Lefevre wrote: > On 2010-11-15 09:24:38 -0800, Bart Schaefer wrote: > > On Nov 15, 5:32pm, Vincent Lefevre wrote: > > } > > } > ypig:~/wd> up > > } > At revision 40202. > > } > zsh: exit 141 > > } > ypig:~/wd[PIPE]> > > } > > } This has just happened again. This time, the machine hadn't been > > } rebooted (but there has been a lot of disk activity before that). > > > > It appears to me that it must be the case that > > svn "$@" > > is exiting with status 141, rather than that the filter function is > > killing its parent with a PIPE signal. > > I don't think this is possible as when svn receives a PIPE signal, > it outputs "svn: Write error: Broken pipe" and exits with status 1. > But I've added some code to check that status 141 is not possible. While the problem described above was not rare, since I modified the script in the following way (two months ago), I can no longer see the problem. -{ svn "$@"; st=$?; echo "svnwrapper:term" >&2 } 2>>(filter) +{ + svn "$@" + st=$? + [[ $st -eq 141 ]] && echo "Exit with status 141!" >&2 + echo "svnwrapper:term" >&2 +} 2>>(filter) So, either the problem has been fixed somewhere or it can no longer be seen due to the change in my script. In the latter case, it is probably a bug in zsh. I'm going to revert this change and see if I can see the problem again... -- Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon) ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: strange behavior 2011-01-28 14:44 ` Vincent Lefevre @ 2011-01-28 15:49 ` Bart Schaefer 2011-01-30 0:37 ` Vincent Lefevre 0 siblings, 1 reply; 13+ messages in thread From: Bart Schaefer @ 2011-01-28 15:49 UTC (permalink / raw) To: zsh-users On Jan 28, 3:44pm, Vincent Lefevre wrote: } Subject: Re: strange behavior } } On 2010-11-16 04:10:23 +0100, Vincent Lefevre wrote: } > On 2010-11-15 09:24:38 -0800, Bart Schaefer wrote: } > > } > > It appears to me that it must be the case that } > > svn "$@" } > > is exiting with status 141, rather than that the filter function is } > > killing its parent with a PIPE signal. } } While the problem described above was not rare, since I modified } the script in the following way (two months ago), I can no longer } see the problem. } } -{ svn "$@"; st=$?; echo "svnwrapper:term" >&2 } 2>>(filter) } +{ } + svn "$@" } + st=$? } + [[ $st -eq 141 ]] && echo "Exit with status 141!" >&2 } + echo "svnwrapper:term" >&2 } +} 2>>(filter) I forget whether we covered this before, but does {svn "$@"} ever fork as part of its execution? There has to be some kind of race condition here. 2>>(filter) runs filter in the background, so if something behind svn also runs as an separate process, it could be possible for the filter to exit and close it's stdin (thereby closing everything else's stdder) before operating-system-level exit-time buffer-flushing has finished. } So, either the problem has been fixed somewhere or it can no longer } be seen due to the change in my script. In the latter case, it is } probably a bug in zsh. I'm going to revert this change and see if } I can see the problem again... Hmm, another thought ... maybe the "zsh: exit 141" is coming from the shell's exit-time handling of the "filter" program, rather than from svn. I've lost enough context here that I don't recall whether that was previously ruled out too. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: strange behavior 2011-01-28 15:49 ` Bart Schaefer @ 2011-01-30 0:37 ` Vincent Lefevre 2011-01-30 22:25 ` Bart Schaefer 0 siblings, 1 reply; 13+ messages in thread From: Vincent Lefevre @ 2011-01-30 0:37 UTC (permalink / raw) To: zsh-users On 2011-01-28 07:49:15 -0800, Bart Schaefer wrote: > I forget whether we covered this before, but does {svn "$@"} ever > fork as part of its execution? Yes (for SSH connection, and the ssh script can start a SSH master connection, which will still run in background after svn terminates, and that's why I needed the svnwrapper:term trick in my script). > There has to be some kind of race condition here. 2>>(filter) runs > filter in the background, so if something behind svn also runs as an > separate process, it could be possible for the filter to exit and > close it's stdin (thereby closing everything else's stdder) before > operating-system-level exit-time buffer-flushing has finished. Yes, this happens, but I don't see why this could make the script terminate with a broken pipe. I recall the whole script: filter() { unset brpipe while true do unset line timeout while read -r $timeout -k -u 0 ch do line="$line$ch" [[ $ch = $'\012' ]] && break timeout=(-t 0.1) done case $line in svnwrapper:term$'\012') break ;; *Broken\ pipe$'\012') brpipe=1 ;; ?*) printf "%s" "$line" >&2 ;; *) break ;; # empty line (end of file) - parent has died? esac done # The "sleep 5" is there to avoid a rare race condition (it occurred # once): make sure the parent process receives the PIPE signal before # the filter process terminates (which can yield a SIGPIPE in svn). [[ -z $brpipe ]] || { kill -PIPE $$; sleep 5 } } { svn "$@"; st=$?; echo "svnwrapper:term" >&2 } 2>>(filter) exit $st Because of the "while true" loop, filter should still run after svn terminates. Note that when I obtained the "zsh: exit 141", the svn output wasn't redirected, so that a "Broken pipe" message from svn was not possible. > Hmm, another thought ... maybe the "zsh: exit 141" is coming from > the shell's exit-time handling of the "filter" program, rather than > from svn. I've lost enough context here that I don't recall whether > that was previously ruled out too. What do you mean here? -- Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon) ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: strange behavior 2011-01-30 0:37 ` Vincent Lefevre @ 2011-01-30 22:25 ` Bart Schaefer 2011-01-31 9:11 ` Vincent Lefevre 2011-04-11 14:26 ` Vincent Lefevre 0 siblings, 2 replies; 13+ messages in thread From: Bart Schaefer @ 2011-01-30 22:25 UTC (permalink / raw) To: zsh-users On Jan 30, 1:37am, Vincent Lefevre wrote: } Subject: Re: strange behavior } } On 2011-01-28 07:49:15 -0800, Bart Schaefer wrote: } > There has to be some kind of race condition here. 2>>(filter) runs } > filter in the background, so if something behind svn also runs as an } > separate process, it could be possible for the filter to exit and } > close it's stdin (thereby closing everything else's stdder) before } > operating-system-level exit-time buffer-flushing has finished. } } Yes, this happens, but I don't see why this could make the script } terminate with a broken pipe. Possible epiphany: zsh prints "zsh: exit 141" like that only if the exit status came from a builtin or shell function (Src/exec.c). For all external commands or subshells it appends the jobtext after the status number (Src/jobs.c). Those are the only PRINTEXITVALUE cases. Thus the exit value of 141 must be coming from one of these places: (1) "read" builtin in the inner loop of "filter" (2) "printf" in the ?* branch of the case in "filter" (3) "echo" in the { ... } expression I can't imagine how "read" could return 141. For the { echo } statement, I get "zsh: broken pipe" every way I try to make it fail, before zsh ever gets around to PRINTEXITVALUE. That leaves "printf" ... Which at first let me to wonder if what's happening is that the inner while loop is failing to consume the entire svnwrapper:term$'\012' in a single pass around the outer loop, e.g. that the -t option you're adding after reading the first character causes read to time out on some calls instead of reading the next character. But that implies that the stderr of "filter" is getting closed somehow, and I can't think of a way that would happen. So I'm still stuck. What we need is an "strace -ff -o ..." or the equivalent to tell which process is printing that, but tracing may resolve the race condition and prevent the error. } Note that when I obtained the "zsh: exit 141", the svn output wasn't } redirected, so that a "Broken pipe" message from svn was not possible. I don't understand what "wasn't redirected" means. Stderr is always redirected; "Broken pipe" could occur if svn prints something to stderr after 2>>(filter) has exited. I still can't figure out how to tie that to "zsh: exit 141" given the constraints above, though. } > Hmm, another thought ... maybe the "zsh: exit 141" is coming from } > the shell's exit-time handling of the "filter" program, rather than } > from svn. I've lost enough context here that I don't recall whether } > that was previously ruled out too. } } What do you mean here? I meant that 2>>(...) is handled specially. Because "filter" is a shell function, it runs in a subshell which might have inherited the printexitvalue setopt from its parent. When filter exits inside the subshell, perhaps the subshell is printing "exit 141" before it also exits. *That* could correspond to printf barfing, but what would be closing the stderr of the command substitution? ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: strange behavior 2011-01-30 22:25 ` Bart Schaefer @ 2011-01-31 9:11 ` Vincent Lefevre 2011-04-11 14:26 ` Vincent Lefevre 1 sibling, 0 replies; 13+ messages in thread From: Vincent Lefevre @ 2011-01-31 9:11 UTC (permalink / raw) To: zsh-users On 2011-01-30 14:25:40 -0800, Bart Schaefer wrote: > So I'm still stuck. What we need is an "strace -ff -o ..." or the > equivalent to tell which process is printing that, but tracing may resolve > the race condition and prevent the error. Yes, and I don't know how to reproduce the error. > } Note that when I obtained the "zsh: exit 141", the svn output wasn't > } redirected, so that a "Broken pipe" message from svn was not possible. > > I don't understand what "wasn't redirected" means. I meant the script output. The error occurred when I ran "svnwrapper up" (no redirections, contrary to "svnwrapper log | head"). -- Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon) ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: strange behavior 2011-01-30 22:25 ` Bart Schaefer 2011-01-31 9:11 ` Vincent Lefevre @ 2011-04-11 14:26 ` Vincent Lefevre 2011-04-11 14:39 ` Vincent Lefevre 1 sibling, 1 reply; 13+ messages in thread From: Vincent Lefevre @ 2011-04-11 14:26 UTC (permalink / raw) To: zsh-users On 2011-01-30 14:25:40 -0800, Bart Schaefer wrote: > Possible epiphany: zsh prints "zsh: exit 141" like that only if the > exit status came from a builtin or shell function (Src/exec.c). For > all external commands or subshells it appends the jobtext after the > status number (Src/jobs.c). Those are the only PRINTEXITVALUE cases. > > Thus the exit value of 141 must be coming from one of these places: > > (1) "read" builtin in the inner loop of "filter" > (2) "printf" in the ?* branch of the case in "filter" > (3) "echo" in the { ... } expression I can reproduce the SIGPIPE problem when resizing the terminal window while the wrapper is being run. According to strace, it's (3). > I can't imagine how "read" could return 141. > > For the { echo } statement, I get "zsh: broken pipe" every way I try > to make it fail, before zsh ever gets around to PRINTEXITVALUE. > > That leaves "printf" ... > > Which at first let me to wonder if what's happening is that the inner > while loop is failing to consume the entire svnwrapper:term$'\012' in > a single pass around the outer loop, e.g. that the -t option you're > adding after reading the first character causes read to time out on > some calls instead of reading the next character. But that implies > that the stderr of "filter" is getting closed somehow, and I can't > think of a way that would happen. > > So I'm still stuck. What we need is an "strace -ff -o ..." or the > equivalent to tell which process is printing that, but tracing may > resolve the race condition and prevent the error. Here's the end of the strace output: access("/home/vlefevre/bin/svnwrapper", F_OK) = 0 stat("/home/vlefevre/bin/svnwrapper", {st_mode=S_IFREG|0755, st_size=2027, ...}) = 0 open("/home/vlefevre/bin/svnwrapper", O_RDONLY|O_NOCTTY) = 3 fcntl(3, F_DUPFD, 10) = 11 close(3) = 0 fcntl(11, F_GETFL) = 0x8000 (flags O_RDONLY|O_LARGEFILE) fstat(11, {st_mode=S_IFREG|0755, st_size=2027, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ffa4ad2c000 lseek(11, 0, SEEK_CUR) = 0 read(11, "#!/usr/bin/env zsh\n\n# svn wrappe"..., 4096) = 2027 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 pipe([3, 5]) = 0 fcntl(3, F_DUPFD, 10) = 12 close(3) = 0 fcntl(5, F_DUPFD, 10) = 13 close(5) = 0 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7ffa4ad399d0) = 19270 close(12) = 0 fcntl(2, F_DUPFD, 10) = 12 close(2) = 0 dup2(13, 2) = 2 close(13) = 0 rt_sigprocmask(SIG_BLOCK, [CHLD], [CHLD], 8) = 0 rt_sigprocmask(SIG_BLOCK, [CHLD], [CHLD], 8) = 0 pipe([3, 5]) = 0 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7ffa4ad399d0) = 19271 close(5) = 0 read(3, "", 1) = 0 close(3) = 0 rt_sigprocmask(SIG_BLOCK, [CHLD], [CHLD], 8) = 0 rt_sigsuspend([INT]) = ? ERESTARTNOHAND (To be restarted) --- SIGCHLD (Child exited) @ 0 (0) --- --- SIGWINCH (Window changed) @ 0 (0) --- rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], [INT CHLD WINCH], 8) = 0 rt_sigprocmask(SIG_SETMASK, [INT CHLD WINCH], ~[KILL STOP RTMIN RT_1], 8) = 0 ioctl(10, TIOCGWINSZ, {ws_row=60, ws_col=85, ws_xpixel=523, ws_ypixel=784}) = 0 rt_sigreturn(0x1c) = 0 rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], [INT CHLD], 8) = 0 rt_sigprocmask(SIG_SETMASK, [INT CHLD], ~[KILL STOP RTMIN RT_1], 8) = 0 wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], WNOHANG|WSTOPPED|WCONTINUED, {ru_utime={0, 0}, ru_stime={0, 0}, ...}) = 19270 wait4(-1, 0x7ffff6dd97ec, WNOHANG|WSTOPPED|WCONTINUED, 0x7ffff6dd9740) = 0 rt_sigreturn(0xffffffff) = -1 EINTR (Interrupted system call) rt_sigprocmask(SIG_BLOCK, [CHLD], [CHLD], 8) = 0 rt_sigsuspend([INT]) = ? ERESTARTNOHAND (To be restarted) --- SIGCHLD (Child exited) @ 0 (0) --- rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], [INT CHLD], 8) = 0 rt_sigprocmask(SIG_SETMASK, [INT CHLD], ~[KILL STOP RTMIN RT_1], 8) = 0 wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], WNOHANG|WSTOPPED|WCONTINUED, {ru_utime={0, 196012}, ru_stime={0, 204012}, ...}) = 19271 wait4(-1, 0x7ffff6dd97ec, WNOHANG|WSTOPPED|WCONTINUED, 0x7ffff6dd9740) = -1 ECHILD (No child processes) rt_sigreturn(0xffffffff) = -1 EINTR (Interrupted system call) rt_sigprocmask(SIG_BLOCK, [CHLD], [CHLD], 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [CHLD], [CHLD], 8) = 0 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [CHLD], [CHLD], 8) = 0 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 dup(2) = 3 fcntl(1, F_DUPFD, 10) = 13 close(1) = 0 dup2(3, 1) = 1 close(3) = 0 write(1, "svnwrapper:term\n", 16) = -1 EPIPE (Broken pipe) --- SIGPIPE (Broken pipe) @ 0 (0) --- +++ killed by SIGPIPE +++ -- Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon) ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: strange behavior 2011-04-11 14:26 ` Vincent Lefevre @ 2011-04-11 14:39 ` Vincent Lefevre 2011-04-11 15:15 ` Peter Stephenson 0 siblings, 1 reply; 13+ messages in thread From: Vincent Lefevre @ 2011-04-11 14:39 UTC (permalink / raw) To: zsh-users On 2011-04-11 16:26:18 +0200, Vincent Lefevre wrote: > On 2011-01-30 14:25:40 -0800, Bart Schaefer wrote: > > Possible epiphany: zsh prints "zsh: exit 141" like that only if the > > exit status came from a builtin or shell function (Src/exec.c). For > > all external commands or subshells it appends the jobtext after the > > status number (Src/jobs.c). Those are the only PRINTEXITVALUE cases. > > > > Thus the exit value of 141 must be coming from one of these places: > > > > (1) "read" builtin in the inner loop of "filter" > > (2) "printf" in the ?* branch of the case in "filter" > > (3) "echo" in the { ... } expression > > I can reproduce the SIGPIPE problem when resizing the terminal window > while the wrapper is being run. According to strace, it's (3). and this is because the SIGWINCH seems to interrupt the "read" (is it a bug?), so that while read -r $timeout -k -u 0 ch do line="$line$ch" [[ $ch = $'\012' ]] && break timeout=(-t 0.1) done gives an empty string; hence the observed behavior. -- Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon) ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: strange behavior 2011-04-11 14:39 ` Vincent Lefevre @ 2011-04-11 15:15 ` Peter Stephenson 2011-04-28 11:32 ` Vincent Lefevre 0 siblings, 1 reply; 13+ messages in thread From: Peter Stephenson @ 2011-04-11 15:15 UTC (permalink / raw) To: zsh-users On Mon, 11 Apr 2011 16:39:30 +0200 Vincent Lefevre <vincent@vinc17.org> wrote: > and this is because the SIGWINCH seems to interrupt the "read" > (is it a bug?), so that > > while read -r $timeout -k -u 0 ch > do > line="$line$ch" > [[ $ch = $'\012' ]] && break > timeout=(-t 0.1) > done > > gives an empty string; hence the observed behavior. Yes, we handle EINTR in most places and should do so here. There are lots of nasty special cases in bin_read(); I think this is this one. Index: Src/builtin.c =================================================================== RCS file: /cvsroot/zsh/zsh/Src/builtin.c,v retrieving revision 1.249 diff -p -u -r1.249 builtin.c --- Src/builtin.c 4 Mar 2011 13:25:26 -0000 1.249 +++ Src/builtin.c 11 Apr 2011 15:13:19 -0000 @@ -5291,9 +5291,16 @@ bin_read(char *name, char **args, Option *bptr = readchar; val = 1; readchar = -1; - } else if ((val = read(readfd, bptr, nchars)) <= 0) { - eof = 1; - break; + } else { + while ((val = read(readfd, bptr, nchars)) < 0) { + if (errno != EINTR || + errflag || retflag || breaks || contflag) + break; + } + if (val <= 0) { + eof = 1; + break; + } } #ifdef MULTIBYTE_SUPPORT -- Peter Stephenson <pws@csr.com> Software Engineer Tel: +44 (0)1223 692070 Cambridge Silicon Radio Limited Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: strange behavior 2011-04-11 15:15 ` Peter Stephenson @ 2011-04-28 11:32 ` Vincent Lefevre 0 siblings, 0 replies; 13+ messages in thread From: Vincent Lefevre @ 2011-04-28 11:32 UTC (permalink / raw) To: zsh-users On 2011-04-11 16:15:27 +0100, Peter Stephenson wrote: > On Mon, 11 Apr 2011 16:39:30 +0200 > Vincent Lefevre <vincent@vinc17.org> wrote: > > and this is because the SIGWINCH seems to interrupt the "read" > > (is it a bug?), so that > > > > while read -r $timeout -k -u 0 ch > > do > > line="$line$ch" > > [[ $ch = $'\012' ]] && break > > timeout=(-t 0.1) > > done > > > > gives an empty string; hence the observed behavior. > > Yes, we handle EINTR in most places and should do so here. There are > lots of nasty special cases in bin_read(); I think this is this one. [...] Thanks, I confirm that the problem has been fixed with the latest zsh-beta upgrade under Debian. -- Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon) ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2011-04-28 11:39 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-11-02 12:09 strange behavior Vincent Lefevre 2010-11-15 16:32 ` Vincent Lefevre 2010-11-15 17:24 ` Bart Schaefer 2010-11-16 3:10 ` Vincent Lefevre 2011-01-28 14:44 ` Vincent Lefevre 2011-01-28 15:49 ` Bart Schaefer 2011-01-30 0:37 ` Vincent Lefevre 2011-01-30 22:25 ` Bart Schaefer 2011-01-31 9:11 ` Vincent Lefevre 2011-04-11 14:26 ` Vincent Lefevre 2011-04-11 14:39 ` Vincent Lefevre 2011-04-11 15:15 ` Peter Stephenson 2011-04-28 11:32 ` 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).