On Wed, Sep 17, 2025 at 08:25:01AM +0200, pourko--- via Bug reports for the GNU Bourne Again SHell wrote: > Some people suggested that my post was not in a suitable form. > So I am rephrasing my original post, with simpler examples: > > cat <<'EOF' >./test0 > #!/bin/bash > [ -t 0 ] && [ -t 1 ] || exit > echo " ==> NOTE: RUNNING." > read -t 0 > echo " ==> NOTE: RETURNING: \$? $?" > EOF > > cat <<'EOF' >./test1 > #!/bin/bash > [ -t 0 ] && [ -t 1 ] || exit > echo " ==> NOTE: RUNNING." > read -t 1 > echo " ==> NOTE: RETURNING: \$? $?" > EOF > > chmod +x ./test0 ./test1 > ./test0 & wait > ./test1 & wait > > RESULTS: > ./test0 finishes execution. > ./test1 gets stuck after echo "RUNNING", and before echo "RETURNING". > > EXPECTED RESULT: Given a timeout option, the read commanad should return > (possibly sooner but no later than) after the timeout expires. > > Alternatively, if "read -t 1" is going to have some such problems (and if > we decide to call that "normal"), then "read -t 0" should be able to > detect such a condition and return with some *meaningful* return code. > > Alternatively (#2), the [ -t N ] tests should be able to help us avoid it. > > Alternatively (#3), there must be some other way to detect such condition, > and avoid getting stuck, without shelling out to external commands. > > Pourko > > --- > [*] As you see, I am not even mentioning my grievances about the "-t 0" > option for not running its test in raw term mode (for historical reasons > I guess), or for not having some other option that could do a non-blocking > read on the raw term input buffer without the need of timeout. >
Can you say something about the version of Bash you're running and on what platform? I can not reproduce the hanging behaviour of "test1" using Bash 5.2.37 on Alpine Linux, nor with 5.2.15 on Debian, or with 5.3.0 buildt from the latest sources on Alpine. -- Matti Andreas Kähäri Uppsala, Sweden .
