Bash – Why Does a While Loop Stop After Being Suspended?

background-processbashshellsignals

Why is it that using bash and suspending a while loop, the loop stops after being resumed? Short example below.

$ while true; do echo .; sleep 1; done
.
.
^Z
[1]+  Stopped                 sleep 1
$ fg
sleep 1
$

I'm familiar with signals, and I'm guessing this may be the natural behaviour of bash here, but I'd like to better understand why it behaves in this particular way.

Best Answer

This looks like a bug in several shells, it works as expected with ksh93 and zsh.

Background:

Most shells seem to run the while loop inside the main shell and

Bourne Shell suspends the whole shell if you type ^Z with a non-login shell

bash suspends only the sleep and then leaves the while loop in favor of printing a new shell prompt

dash makes this command unsuspendable

With ksh93, things work very different:

ksh93 does the same, while the command is started the first time, but as sleep is a buitin in ksh93, ksh93 has a handler that causes the while loop to fork off the main shell and then suspend at the time when you type ^Z.

If you in ksh93 later type fg, the forked off child that still runs the loop is continued.

You see the main difference when comparing the jobcontrol messages from bash and ksh93:

bash reports:

[1]+ Stopped sleep 1

but ksh93 reports:

^Z[1] + Stopped while true; do echo .; sleep 1; done

zsh behaves similar to ksh93

With both shells, you have a single process (the main shell) as long as you don't type ^Z, and two shell processes after you typed ^Z.

Related Solutions

Bash – Why does while [ 0 ] go into infinite loop

Single square brackets in the shell is a synonym for test (either the separate command or the shell built-in), so [ 0 ] means the same thing as test 0. test is for doing comparisons and testing the attributes of files, as you can read about in its manpage. When it isn't given an expression that looks like a comparison, file test, or one of the other operations it can do, it will instead test if the argument is present and a non-empty string. Neither 0 or 1 are really appropriate inputs for test, and as non-empty strings test simply succeeds and your while loop loops forever.

You may want to try instead

while false; do
  echo "hello"
done

possibly replacing false with true. Or maybe what you want is to use (( )):

while (( 0 )); do
  echo "hello"
done

Which will behave like most languages, where 0 means failure/false and 1 means success/true.

Bash – Why does Bash ignore SIGINT if its currently running child handles it

The problem is well explained here, as WCE wait and cooperative exit and I encourage you to read it. Basically, your signal is received by all foreground processes, ie the shell and the program, sleep or aplay. The program exits with return code 130 if it does not handle the signal. The shell does a wait for the child to end, and sees this, and the fact that it got the signal too, so exits.

When the program captures the signal, it often just exits with code 1 (as with aplay). When the shell waits for the child, it sees that it did not end due to the signal and so has to assume the signal was a normal aspect of the program's working, so the shell carries on as normal.

For your example, the best way to handle aplay is to check its return code for non-zero and stop:

(while aplay test.wav; do :; done)

The above-mentioned article goes on to explain that a well-behaved program that wants to trap sigint to do some cleanup, should then disable its handler, and re-kill itself in order to get the correct exit flags set.

Best Answer

Related Solutions

Bash – Why does while [ 0 ] go into infinite loop

Bash – Why does Bash ignore SIGINT if its currently running child handles it

Related Question