After many, many hours of searching the face of the Internet, I have found the answer.

1. Linux has the notion of a process group.

2. The TTY driver has a notion of Foreground Process Group.

3. When you press Ctrl+C, the TTY sends SIGINT to every process in the Foreground Process Group. (See also this blog entry.)

This is why both the compiled binary and the script that launches it both get clobbered. In fact I only want the main application to receive this signal, not the startup scripts.

The solution is now obvious: We need to put the application in a new process group, and make it the Foreground Process Group for this TTY. Apparently the command to do that is

setsid -c <applcation> 

And that is all. Now when the user presses Ctrl+C, SIGINT will be sent to the application (and any children it may have) and nobody else. Which is what I wanted.

• setsid by itself puts the application in a new process group (indeed, an entire new "session", which is apparently a group of process groups).

• Adding the -c flag makes this new process group become the "foreground" process group for the current TTY. (I.e., it gets SIGINT when you press Ctrl+C.)

I've seen a lot of conflicting information about when Bash does or does not run processes in a new process group. (In particular, it appears to be different for "interactive" and "non-interactive" shells.) I've seen suggestions that you can maybe get this to work with clever pipe trickery... I don't know. But the approach above seems to work for me.

After many, many hours of searching the face of the Internet, I have found the answer.

1. Linux has the notion of a process group.

2. The TTY driver has a notion of Foreground Process Group.

3. When you press Ctrl+C, the TTY sends SIGINT to every process in the Foreground Process Group. (See also this blog entry.)

This is why both the compiled binary and the script that launches it both get clobbered. In fact I only want the main application to receive this signal, not the startup scripts.

The solution is now obvious: We need to put the application in a new process group, and make it the Foreground Process Group for this TTY. Apparently the command to do that is

setsid -c <applcation> 

And that is all. Now when the user presses Ctrl+C, SIGINT will be sent to the application (and any children it may have) and nobody else. Which is what I wanted.

• setsid by itself puts the application in a new process group (indeed, an entire new "session", which is apparently a group of process groups).

• Adding the -c flag makes this new process group become the "foreground" process group for the current TTY. (I.e., it gets SIGINT when you press Ctrl+C)

I've seen a lot of conflicting information about when Bash does or does not run processes in a new process group. (In particular, it appears to be different for "interactive" and "non-interactive" shells.) I've seen suggestions that you can maybe get this to work with clever pipe trickery... I don't know. But the approach above seems to work for me.

After many, many hours of searching the face of the Internet, I have found the answer.

1. Linux has the notion of a progress group.

2. The TTY driver has a notion of Foreground Process Group.

3. When you press Ctrl+C, the TTY sends SIGINT to every process in the Foreground Process Group. (See also this blog entry.)

This is why both the compiled binary and the script that launches it both get clobbered. In fact I only want the main application to receive this signal, not the startup scripts.

The solution is now obvious: We need to put the application in a new process group, and make it the Foreground Process Group for this TTY. Apparently the command to do that is

setsid -c <applcation> 

And that is all. Now when the user presses Ctrl+C, SIGINT will be sent to the application (and any children it may have) and nobody else. Which is what I wanted.

• setsid by itself puts the application in a new process group (indeed, an entire new "session", which is apparently a group of process groups).

• Adding the -c flag makes this new process group become the "foreground" process group for the current TTY. (I.e., it gets SIGINT when you press Ctrl+C.)

I've seen a lot of conflicting information about when Bash does or does not run processes in a new process group. (In particular, it appears to be different for "interactive" and "non-interactive" shells.) I've seen suggestions that you can maybe get this to work with clever pipe trickery... I don't know. But the approach above seems to work for me.

After many, many hours of searching the face of the Internet, I have found the answer.

1. Linux has the notion of a process group.

2. The TTY driver has a notion of Foreground Process Group.

3. When you press Ctrl+C, the TTY sends SIGINT to every process in the Foreground Process Group. (See also this blog entry.)

This is why both the compiled binary and the script that launches it both get clobbered. In fact I only want the main application to receive this signal, not the startup scripts.

The solution is now obvious: We need to put the application in a new process group, and make it the Foreground Process Group for this TTY. Apparently the command to do that is

setsid -c <applcation> 

And that is all. Now when the user presses Ctrl+C, SIGINT will be sent to the application (and any children it may have) and nobody else. Which is what I wanted.

• setsid by itself puts the application in a new process group (indeed, an entire new "session", which is apparently a group of process groups).

• Adding the -c flag makes this new process group become the "foreground" process group for the current TTY. (I.e., it gets SIGINT when you press Ctrl+C.)

I've seen a lot of conflicting information about when Bash does or does not run processes in a new process group. (In particular, it appears to be different for "interactive" and "non-interactive" shells.) I've seen suggestions that you can maybe get this to work with clever pipe trickery... I don't know. But the approach above seems to work for me.