Kevin Brodsky wrote:
> The thing is, "the next level of the program" really is another program,
> i.e. the one that invoked it, and you are communicating via the exit
> status, so it's certainly not as explicit as re-throwing an exception in
> C++, for instance. But sure, once you are aware of this
On 05/08/2017 20:35, Bob Proulx wrote:
>
> Really? It seems intuitive to me that at any trap handling level one
> should handle what needs to be handled and then raise the signal
> higher to the next level of the program. Software is all about layers
> and abstraction. Sending the signal to one
Kevin Brodsky wrote:
> To be fair, killing oneself when receiving SIGINT is quite
> counter-intuitive, POSIX is not helping here.
Really? It seems intuitive to me that at any trap handling level one
should handle what needs to be handled and then raise the signal
higher to the next level of the p
On 05/08/2017 03:22, Bob Proulx wrote:
> Kevin Brodsky wrote:
>> $ bash -c '(trap "echo INT; exit 1" INT; sleep 60s); echo after'
>> ^CINT
>> after
>> $
> This is a good example of a bad example case. You shouldn't "exit 1"
> or you will replace the information that the process is exiting due to
>
On 05/08/2017 15:53, Chet Ramey wrote:
> On 8/4/17 7:52 PM, Kevin Brodsky wrote:
>
>> When Bash receives SIGINT while executing a command, it normally waits
>> for the command to complete, and then aborts execution. However, it
>> looks like somehow, this is not the case if the command handles SIGI
On 8/4/17 7:52 PM, Kevin Brodsky wrote:
> When Bash receives SIGINT while executing a command, it normally waits
> for the command to complete, and then aborts execution. However, it
> looks like somehow, this is not the case if the command handles SIGINT,
> and execution continues after the comma
Kevin Brodsky wrote:
> $ bash -c '(trap "echo INT; exit 1" INT; sleep 60s); echo after'
> ^CINT
> after
> $
This is a good example of a bad example case. You shouldn't "exit 1"
or you will replace the information that the process is exiting due to
a signal with an error code. The trap handler sh
Hi,
I have run into a rather weird behaviour related to SIGINT, which
doesn't seem to be intended, as it's not consistent with other shells
(and is so unexpected that it took me a while to figure out what was
going wrong in my script!).
When Bash receives SIGINT while executing a command, it norm
