New answers tagged signals
In your initiating bash script. keep track of the PID of the second program catch the SIGINT when you have caught a SIGINT, send a SIGINT to the second program PID HTH
The first column mean the signal that is sent. Use kill -l for a list of all signal that are available on your system (see the oracle documentation for the meaning of the signals, here the most important ones). The second column indicates whether the signal is caught by a signal handler of the process or not. caught means that there is a signal handler ...
This is behavior specific to dd. From the dd man page: Sending a USR1 signal to a running 'dd' process makes it print I/O statistics to standard error and then resume copying. $ dd if=/dev/zero of=/dev/null& pid=$! $ kill -USR1 $pid; sleep 1; kill $pid 18335302+0 records in 18335302+0 records out 9387674624 bytes (9.4 GB) copied, 34.6279 ...
ssh can be invoked in a few different ways, each resulting slightly different treatment of terminal-initiated signals like Ctrl-C. ssh remotehost will run an interactive session on remotehost. On the client side, ssh will try to set the tty used by stdin to "raw" mode, and sshd on the remote host will allocate a pseudo-tty and run your shell as a login ...
Answering my own question: This is a known issue with Sun SSH. The best workaround I found is to detect "Sun_SSH" in output of ssh -V and apply something like this: #!/bin/bash # .... ( ssh host 'localCommand' | remoteCommand || pkill -P $BASHPID ) You may also use $$ instead of $BASHPID in other shells or in simpler situations (if your shell doesn't have ...
Running the command trap - INT QUIT from a shell should restore the default signal handling for that shell and the processes that it subsequently executes. You may want to add this to your ~/.profile. Check if some initialization file somewhere contains trap "" INT QUIT or something similar (which tells the shell to ignore the signal).
Top 50 recent answers are included