Belated hello all,
Probably 15 years too late for Bernd, but perhaps useful info for those
encountering similar issues in 2026:
timeout has had a `--foreground` flag for a while now, but it's quite
unintuitive - why does timeout behave as I'm expecting on simple commands
in the shell, only to ignore keyboard signal handling when that exact same
shell snippet is invoked as part of an actual shell script?
I can see the rationale for --foreground not being default, because you
want all children to be killed rather than having stragglers, but for
simple commands that you just wanted to have a reliable timeout for
And testing in the shell, being a subshell is sufficient to trigger this
behaviour in timeout:
timeout 10 bash -c "read a; echo \$a"
exits immediately when fed input, can be CTRL-c'd.
vs
a=$(timeout 10 bash -c "read a; echo \$a")
hangs for 10 seconds, never reads from the terminal, the entered data just
appears at the next shell prompt.
vs
a=$(timeout --foreground 10 bash -c "read a; echo \$a")
works as expected for both input and CTRL-c.
even just plain old subshells not trying to capture that input are
affected:
> asd() {
> timeout 10 bash -c "read a; echo \$a"
> }
> asd
^C
> (asd)
^Casdfsaf
> asdfsaf
bash: asdfsaf: command not found
I wish there were better tradeoff between making sure children are killed
by default, but not blocking signals and TTY reading, and thoroughly
different behaviour between interactive shell and shell scripted
behaviour!
--
Tim Connors
