Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > gnu.bash.bug > #15756
| From | Chet Ramey <chet.ramey@case.edu> |
|---|---|
| Newsgroups | gnu.bash.bug |
| Subject | Re: read -t 0 fails to detect input. |
| Date | 2019-12-19 11:40 -0500 |
| Message-ID | <mailman.1140.1576773608.1979.bug-bash@gnu.org> (permalink) |
| References | <CAFra36gNku2DTCyivz+caMGnTf7GvGJUTiWicUnBZatcckXGcQ@mail.gmail.com> <7e6fccb4-e5b5-eb2b-8b12-eeee9d638ae1@case.edu> |
On 12/18/19 6:40 PM, Bize Ma wrote: > It seems that read -t 0 should detect if there is input from a pipe (and > others). > > From man bash: > >>> If timeout is 0, read returns immediately, without trying to read any > data. >>> The exit status is 0 if input is available on the specified file > descriptor, non-zero otherwise. Bash-5.0 uses select/FIONREAD to determine whether or not there is input available on the file descriptor. Those don't wait; they test whether or not there is input on the specified file descriptor at the point they are called. > > So, it seems that this should print 1: > > $ true | read -t 0 var; echo $? > 1 > > And this should print 0 (input available), but it doesn't (most of the > time). > > $ echo value | read -t 0 var ; echo $? > 1 This is inherently racy: there is no guarantee that the echo will have written anything to the pipe by the time the read runs to test it. It depends on how the system schedules the processes. -- ``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/
Back to gnu.bash.bug | Previous | Next | Find similar | Unroll thread
Re: read -t 0 fails to detect input. Chet Ramey <chet.ramey@case.edu> - 2019-12-19 11:40 -0500
csiph-web