there is a case , u [[ $readreply ]] after read On Monday, October 7, 2024, Thomas Oettli via Bug reports for the GNU Bourne Again SHell <bug-bash@gnu.org> wrote:
> I agree with you, but it should never happen that read returns timeout, > also returns the full line and has already read the newline character. > If that happens, there is no way for the script to decide what to do. > Please see the provided test script, it showcases the error. > > If I did a mistake there, I would gladly change it. But I currently don't > see any way how to handle this properly from the script side. > > Please also see the answer from Martin D Kealey, I think he is on to > something: > https://lists.gnu.org/archive/html/bug-bash/2024-10/msg00007.html > > > > > On 10/4/24 8:18 AM, Thomas Oettli via Bug reports for the GNU Bourne Again > SHell wrote: > > > Bash Version: 5.2 > > Patch Level: 26 > > Release Status: release > > > > Description: > > I have tried to write a bash script that asynchronously reads from a > pipe (line by line) with the help of "read -t". > > If the timeout occurs in just the right moment, read returns the full > line, but the return code says timeout (rc > 128). > > If the read command times out, it always returns > 128, so if you have a > return code in that range, you can assume read timed out and react > accordingly. > > > Therefor it is not possible to know if a full line was returned or not. > > When read times out, it always returns what it read before the timeout in > the buffer, so you don't lose any data. Whether or not that's a `full line' > is up to timing, and it's up to the script to decide how to cope with it. > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/ > >
