Re: read command sometimes misses newline on timeout

[alex xmb sw ratchev]

well try remove the -n in echo

On Monday, October 7, 2024, Thomas Oettli <thomas.oettli@sfs.com> wrote:

> Sorry Alex, I don't understand exactly what you mean.
> Here is the Test-Script again with some comments:
>
>     function reader() {
>       local buf line
>       while :; do
>         read -t .01 buf                  # try to read line to $buf with 
> timeout
>         rc=$?
>         if (( rc == 0 )); then           # got a full line or the rest of a 
> partial line, append $buf to $line
>           line+=$buf
>         elif (( rc > 128 )); then        # ran into timeout
>           line+=$buf                     # maybe received partial line, 
> append $buf to $line and continue reading
>           continue
>         fi
>
>         # at this point, the content of $line should always be "TEST"
>
>         [[ $line != TEST ]] && echo Invalid line: $line && exit
>         echo OK
>         line=""                          # prepare to read next line, set 
> $line to empty string
>       done
>     }
>     reader < <(
>       while :; do
>         echo -n TEST
>         sleep .00$(($RANDOM%10))
>         echo
>       done
>     )
>
>
> Could you please explain to me, where exactly the mistake is? I don't know
> if you ran the script by yourself, but on all of my machines it exits after
> just a few seconds
> with the following output:
>
> Invalid line: TESTTEST
> ------------------------------
> *Von:* alex xmb sw ratchev <fxmbsw7@gmail.com>
> *Gesendet:* Montag, 7. Oktober 2024 16:41
> *An:* Thomas Oettli <thomas.oettli@sfs.com>
> *Cc:* bug-bash@gnu.org <bug-bash@gnu.org>; chet.ramey@case.edu <
> chet.ramey@case.edu>
> *Betreff:* [EXT] Re: read command sometimes misses newline on timeout
>
> CAUTION: This email originated from outside the SFS organization. Do not
> follow guidance, click links or open attachments unless you recognize the
> sender and know the content is safe.
> MAIL FROM:  <@fxmbsw7@gmail.com> Report as Spam / Check Mail
> <https://mail1.sfs.biz/pyquarantine.php?quarantine=orig&action=report_or_check&mailfrom=fxmbsw7%40gmail.com&id=20241007164140_2F94A29C1A462>
>
> 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 chet@case.edu http://tiswww.cwru.edu/~chet/
>
>