bash: Ctrl+C not working in some complex loops

leniviy · 06-28-2010, 07:40 AM

Run the following script in bash and try to interrupt it the with Ctrl+C

Code:

  { echo 1; echo 2; echo 3; } | while read a; do
    echo $a
    { echo 1; echo 2; echo 3; } | while read b; do 
      echo $a-$b
      sleep 1
    done
  done

It won't interrupt. Bug or feature?
In zsh or old plain sh it works.

druuna · 06-28-2010, 08:09 AM

Hi,

What do you mean by "Not working"? Did you expect the script to complete stop running?

Every time you press ctrl-c the while loop the script is in is interrupted (the inner loop, which is then started again with the next entry from the outer loop). Which suggests that ctrl-c is working.

From man bash:

Quote:

while list; do list; done
The while command continuously executes the do list as long as the last command in list returns an exit status of zero

Hope this helps.

leniviy · 06-28-2010, 01:01 PM

Quote:

Originally Posted by druuna

Did you expect the script to complete stop running?

Yes.. what's wrong with that?

Quote:

Originally Posted by druuna

Every time you press ctrl-c the while loop the script is in is interrupted (the inner loop, which is then started again with the next entry from the outer loop).

Actually, the inner loop is interrupted only once. All subsequent pressings of ctrl-c are ignored.

catkin · 06-28-2010, 01:09 PM

Try removing the sleep. I have half an idea that bash is sending the interrupt to the sleep and not acting on it itself except in the unlikely event that you send the interrupt when sleep is not running.

druuna · 06-28-2010, 01:21 PM

Hi,

Running your code I can interrupt the inner loop 3 times, the first (outer) loop keeps running:

Code:

$ ./blaat 
1
1-1
1-2    ctrl-c pressed
2
2-1    ctrl-c pressed
3
3-1
3-2
3-3
$
$ cat blaat 
#!/bin/bash

 { echo 1; echo 2; echo 3; } | while read a; do
    echo $a
    { echo 1; echo 2; echo 3; } | while read b; do 
      echo $a-$b
      sleep 1
    done
  done
$

Nothing is ignored, the script keeps running (example is interrupted twice).

The only thing I can come up with I already posted in #2 (the quote from bash).

leniviy · 06-28-2010, 01:38 PM

I didn't save a file, just pasted the code into the shell. That's why the difference.
But even when executing a file, ctrl-c still doesn't work as it should.

druuna · 06-29-2010, 01:54 PM

Hi,

I've taken a second look at this and catkin is correct: sleep is the culprit.

A strace on the above mentioned code shows that the sleep command is executed as a child and the ctrl-c is caught by that child process.

This also explains the behavior of the (mother) script: If sleep is not interrupted it has an exit code that is zero, if you do interrupt it it will have a non-zero exit code. This exit code is given as return value to the mother and is picked up by the while loop as the "do list" is done, I can exit the loop and the script will continue.

Up to you to decide if this is "works as designed" or not, but it does explain the behavior.

leniviy · 06-29-2010, 03:17 PM

The current bash maintainers have replied to my bugreport:

Quote:

Originally Posted by Chet

Thanks for the report. The key is the shell control structure in a
pipeline calling an external command that dies due to SIGINT. This
will be fixed in bash-4.2.

Honestly, I didn't understand a word.

catkin · 06-29-2010, 10:33 PM

Quote:

Originally Posted by leniviy

Honestly, I didn't understand a word.

I don't have crystal clarity either but ...

In the simple case, when a bash script is launched from the command prompt and the user presses Ctrl+C, this generates an interrupt signal (SIGINT) which is sent from the terminal to all processes associated with the terminal. The running bash script receives it and exits.

Getting a little more complicated, when the bash script sets up a pipeline, bash creates a child process for each command in the pipeline. Now there's a potential problem; if the bash script exited on receiving SIGINT and its child processes did not then the children would be orphans (sad!) and worse, could turn into zombies (plenty on zombie processes on the 'net).

To avoid this, when bash sets up a pipeline it also configures itself to ignore SIGINT. Which is great for avoiding zombies but does mean, as you have found out, that the script itself can no longer be killed from the terminal using Ctrl+C.

AFAIK that is how it is from the perspective of bash, controlling terminals, processes and SIGINT. Switching to the bash maintainers' perspective, bash is written in C. I guess "the shell control structure" is actually a C structure (a type of C variable comprising several primitive variable types) which is used to control what bash does with a pipleline (there is probably one such structure per simple command in the pipeline).

Perhaps the maintainer means bash 4.2 will no longer discard any SIGINTs received when it is running a pipeline but will hold them as pending until the pipeline terminates and then action the pending SIGINT(s) in the normal way.

That would be great! It would solve a weakness of shell script as a programming tool dating from the origins of shell script.

ActiveMan · 08-20-2012, 03:32 AM

Just use trap to exit:

Code:

trap "exit" INT

while true; do
 $*;
done