Timeline for Ksh loses data after piping 16K bytes
Current License: CC BY-SA 3.0
14 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 31, 2012 at 16:54 | comment | added | Tim Kennedy | incidentally, /usr/bin/ksh, on Solaris 11 (11/11 + SRU 13.4) works as expected. | |
| Dec 19, 2012 at 9:29 | history | edited | Peter Miklos | CC BY-SA 3.0 | added 895 characters in body |
| Dec 19, 2012 at 9:24 | vote | accept | Peter Miklos | ||
| Dec 18, 2012 at 21:33 | answer | added | Stéphane Chazelas | timeline score: 7 | |
| Dec 18, 2012 at 15:00 | comment | added | Stéphane Chazelas | No, because it's the parent that gets the SIGCLD, not the subshell. | |
| Dec 18, 2012 at 14:03 | comment | added | Peter Miklos | Thanks for the explanation Stephane. Indeed, using a subshell when doing echo provides a workaround to this issue. And why does it work :) ? Because ksh waits until the subshell completes? | |
| Dec 18, 2012 at 13:04 | comment | added | Stéphane Chazelas | It would make more sense to add that information to the question. Also, it would be helpful to see whether it's the first echo or the second that gets interrupted (like change the second to "echo x$datafile"). It looks like a ksh bug indeed. I suspect ksh doesn't wait for the "file" command to terminate (just wait until EOF when reading its output), and the SIGCLD are handled later on. It's fine in the general case, but when writing to a full pipe, the write for that echo is blocking so likely to be interrupted by the SIGCLD. Doing (echo ...), that is use a subshell, might WA the problem. | |
| Dec 18, 2012 at 12:56 | history | edited | Peter Miklos | CC BY-SA 3.0 | added 570 characters in body |
| Dec 18, 2012 at 12:39 | comment | added | Peter Miklos | running with truss I can see something abnormal, though I don't really know what it means: ioctl(0, I_PEEK, 0x08046B40) = 0 Received signal #18, SIGCLD, in write() [caught] siginfo: SIGCLD CLD_EXITED pid=6561 status=0x0000 write(1, " 0 1 2 3 4 5 6 7 8 9 A B".., 64) Err#4 EINTR lwp_sigmask(SIG_SETMASK, 0x00020000, 0x00000000) = 0xFFBFFEFF [0x0000FFFF] setcontext(0x08046670) read(0, 0x0809064C, 1) = 0 ioctl(0, TCGETA, 0x08046B18) Err#22 EINVAL | |
| Dec 18, 2012 at 12:36 | comment | added | Peter Miklos | using /usr/dt/bin/dtksh also works fine. | |
| Dec 18, 2012 at 12:31 | comment | added | Peter Miklos | Yes, I also tried on linux using PD KSH v5.2.14 and it just works fine. Actually I am not sure what Ksh version is shipped with SunOS 5.10, something like this: grep -i ver /usr/bin/ksh @(#)Version M-11/16/88i | |
| Dec 18, 2012 at 10:40 | comment | added | Stéphane Chazelas | Try running the script with truss to see what's going on. small writes are meant to be atomic on pipes, but ksh is known sometimes to use sockets instead of pipes for shell pipes. Also, ksh is known to do wild optimisations that sometimes affect behavior. truss will tell you if for instance ksh does one write(2) per echo or if some write(2) fail or are partial. You could also use lsof to check whether ksh uses pipes or sockets. FWIW, I can't reproduce it with ksh93u+ on Linux. What version of ksh are you using? | |
| Dec 18, 2012 at 10:09 | review | First posts | |||
| Dec 18, 2012 at 11:34 | |||||
| Dec 18, 2012 at 9:50 | history | asked | Peter Miklos | CC BY-SA 3.0 |