> ---------- Forwarded message ---------- > From: *Thomas Oettli* <thomas.oet...@sfs.com>
> 1. the script calls "read" on pipe > 2. "read" hits timeout just after it has read "\n" from the pipe > 3. "read" returns the full line, but exits with rc > 128 > 4. the script assumes a partial line, appends received data to a buffer > and calls "read" again, but without timeout to get the rest of the line > 5. because "\n" was already read at step 2, "read" returns the next line > 6. script appends received data to the buffer to complete the line (due > to wrong rc from step 3) > > The result is two lines in the buffer (without "\n" in between). Do you > understand now what I mean? If bash is returning nonzero status after reading a full line, then that may be a bug that should be fixed. Martin may be looking into that. Meanwhile, your step 4 looks wrong to me. If you're using an asynchronous reader which expects and works around input delays, then suddenly deciding to call read *without* the -t option seems strange. If you believe you've got a partial line, then I would expect the next call to read would be just like the first call. You might get another part of the line, without seeing the end of the line. It might take several calls before you get a full line. Of course, fixing step 4 to use multiple calls with timeouts instead of one blocking call won't help you if bash is in fact returning false failure codes. (Note for help-bash readers: this thread began on bug-bash, but a private message was sent to one responder, who then forwarded it to help-bash, perhaps by mistake. I'm Cc'ing bug-bash on this, and I'd advise responders to keep this on bug-bash if possible.)
