Tag Info

New answers tagged

0

It turns out enabling job control does the trick — but only if there's no SIGSEGV trap, setting that prevents the verbose output. set -o errexit set -o pipefail set -o monitor trap 'echo "ERR $?"' ERR echo "hi" | ./docrash | cat echo "not reached" Running this gives exactly the output I was looking for, and more. It prints the PID for each child and shows ...


1

If the recipient has time to start processing a signal before the next one comes, then all the signals will be handled in order. When a process receives a signal but isn't ready to handle it (e.g. the signal is masked, or the process is stopped), the kernel marks the signal as pending. The signal will be delivered. If multiple signals of different numbers ...


1

The signals are sent in the order that you type them via the terminal to the kernel. If you use Ctrl+C you're instructing the kernel to send the signal SIGINT, to the foreground process group. Upon receiving this, the command that was running will be terminated. With a Ctrl+Z you're sending the signal SIGSTP. Which doesn't actually kill the process, just ...


3

Part of your problem is that you have the >> trap.log outside the (quoted) command arg, so all you’re getting in the trap.log file is the output from the trap command itself – which is nothing. I’m not sure what you mean by saying “TRAPPED & READY” when your script is terminating, but it looks like what you mean is trap 'rm -f filename; echo ...


2

Use EXIT instead of the signal numbers. The script below works for me. I use the constants. > cat test.sh #!/bin/bash trap 'echo trap' EXIT echo 'Program running' sleep 1 > ./test.sh Program running trap From the bash manpage: If a sigspec is EXIT (0) the command arg is executed on exit from the shell. If a sigspec is DEBUG, the command ...


0

The question contains its own answer. Sending the SIGINT to the cat process with kill is a perfect simulation of what happens when you press ^C. To be more precise, the interrupt character (^C by default) sends SIGINT to every process in the terminal's foreground process group. If instead of cat you were running a more complicated command involving multiple ...


5

How CTRL+C works The first thing is to understand how CTRL+C works. When you press CTRL+C, your terminal emulator sends an ETX character (end-of-text / 0x03). The terminal is configured such that when it receives this character, it sends a SIGINT to the foreground process group of the terminal. This configuration can be viewed by doing stty and looking at ...


5

As vinc17 says, there’s no reason for this to happen.  When you type a signal-generating key sequence (e.g., Ctrl+C), the signal is sent to all processes that are attached to (associated with) the terminal.  There is no such mechanism for signals generated by kill. However, a command like kill -SIGINT -12345 will send the signal to all processes in ...


2

There's no reason to propagate the SIGINT to the child. Moreover the system() POSIX specification says: "The system() function shall ignore the SIGINT and SIGQUIT signals, and shall block the SIGCHLD signal, while waiting for the command to terminate." If the shell propagated the received SIGINT, e.g. following a real Ctrl-C, this would mean that the child ...


1

Yes, there is a difference. This script will exit when you press Enter, or send it SIGINT or SIGTERM: trap '' EXIT echo ' --- press ENTER to close --- ' read response This script will exit when you press Enter: trap '' EXIT INT TERM echo ' --- press ENTER to close --- ' read response * Tested in sh, Bash, and Zsh.   (no longer works in sh when you add ...



Top 50 recent answers are included