Why does bash 'read' exit with status 1?

Question

From an answer to "Bash script doesn't see SIGHUP?", I've got the following in my script:

while true; do read; done

And, usually, this works fine. However, when run from (tl;dr) ... something else, read exits with status code 1.

Why? And how can I deal with this and restore the desired behaviour (correctly triggering the EXIT trap)?

(The "something else" is GNU make running Erlang's ct_run, which uses erlexec to run the script)

When you run the code from something else, does it have a standard input stream? — Kusalananda, Jun 20 '18 at 09:43
What is that loop supposed to do? You don't seem to be using the value read by read, and neither is the exit code checked... — ilkkachu, Jun 20 '18 at 09:48
"Does it have a standard input stream?". Probably not. How do I check? — Roger Lipscombe, Jun 20 '18 at 10:04
The loop is supposed to allow interruption with Ctrl+C, so that the EXIT trap is run. Using something like a simple cat at the end of the script allows Ctrl+C, but doesn't run the trap. — Roger Lipscombe, Jun 20 '18 at 10:04

score 1 · Answer 1 · answered Jun 20 '18 at 09:48

The read documentation in the bash man page says

The exit status is zero, unless end-of-file is encountered, read times out (in which case the status is greater than 128), a variable assignment error (such as assigning to a readonly variable) occurs, or an invalid file descriptor is supplied as the argument to -u.

In your case I suspect standard input is reaching end-of-file.

Since you’re trying to wait indefinitely while still allowing CtrlC, perhaps the following would work better:

while sleep 1; do :; done

This avoids surprises related to I/O handling and ensures a timely reaction to signals.

Why does bash 'read' exit with status 1?

1 Answers1