Re: [50 character or so descriptive subject here (for reference)]

[Chet Ramey]

> Machine Type: i386-pc-linux-gnu
> 
> Bash Version: 2.05
> Patch Level: 0
> Release Status: release
> 
> Description:
>       A python script which is started from .bash_profile in the background
>       is killed by ctrl-c on the command line. The same however has no effect
>       on a perl script. I've tried this on bash 1.14.7, and it behaved as
>       expected - bg jobs are unaffected by a ctrl-c. Also, this does not 
> happen
>       if the script is started manually in the background.

Jobs started from the shell startup files are started without job
control, as you discovered.  This means that they're in the same
process group as the shell.  A keyboard SIGINT is sent to the current
foreground process group by the tty driver, so the shell has to do
something special to keep background non-job-control jobs from getting
SIGINT.  What it does is set the handlers for SIGINT and SIGQUIT to
SIG_IGN when an asynchronous job is started without job control. 

A simple test I just performed on FreeBSD-4.2 indicates that this
works as intended, at least with a shell script that traps SIGINT and
prints a message.  Starting this script in the background (with `&')
from ~/.bashrc and hitting ^C doesn't result in any message, and the
job is still alive. 

I assume that python is installing its own handler for SIGINT when it
executes these lines:

>       except KeyboardInterrupt:
>               print "Caught ctrl-c - exiting..."

Well, if it undoes the work the shell does to insulate it from SIGINT,
it will recieve the signal.

I suppose you could enable job control manually before starting the
python script.  That would put the script into a separate process group.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
( ``Discere est Dolere'' -- chet)

Chet Ramey, CWRU    chet@po.CWRU.Edu    http://cnswww.cns.cwru.edu/~chet/