I oversimplified my original post, so here is the CORRECTED version: BTW, I am reproducing the problem with both bash-5.2.37 on Alpine, and with bash-5.3.3 on Slackware.
cat <<'EOF' >./test0 #!/bin/bash [ -t 0 ] && [ -t 1 ] || exit echo " ==> NOTE: RUNNING." read -d "" -t 0 echo " ==> NOTE: RETURNING: \$? $?" EOF cat <<'EOF' >./test1 #!/bin/bash [ -t 0 ] && [ -t 1 ] || exit echo " ==> NOTE: RUNNING." read -d "" -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 "-t 1" is going to have some such problems (and if we decide to call that "normal"), then "-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.
