Re: Execution continuing after SIGINT received

2017-08-05 Thread Kevin Brodsky
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

Re: Execution continuing after SIGINT received

2017-08-05 Thread Kevin Brodsky
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

Re: Execution continuing after SIGINT received

2017-08-05 Thread Kevin Brodsky
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 cas

Execution continuing after SIGINT received

2017-08-04 Thread Kevin Brodsky
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

Re: Unexpected word splitting on $* when IFS is unset

2017-06-21 Thread Kevin Brodsky
On 21/06/2017 20:29, Chet Ramey wrote: > On 6/21/17 2:43 PM, Kevin Brodsky wrote: > >> That is also my reading of POSIX (and that's more or less what Bash's >> manpage says as well), but it doesn't seem to be the case (even in <=4.2): > That's a rel

Re: Unexpected word splitting on $* when IFS is unset

2017-06-21 Thread Kevin Brodsky
On 21/06/2017 14:54, Chet Ramey wrote: > On 6/20/17 1:33 AM, Eduardo A. Bustamante López wrote: >> On Tue, Jun 20, 2017 at 01:13:07AM +0100, Kevin Brodsky wrote: >> [...] >>> When IFS is unset, unquoted $* undergoes word splitting as if IFS=' ', >>> and n

Re: Unexpected word splitting on $* when IFS is unset

2017-06-20 Thread Kevin Brodsky
On 20/06/2017 06:33, Eduardo A. Bustamante López wrote: > On Tue, Jun 20, 2017 at 01:13:07AM +0100, Kevin Brodsky wrote: > [...] >> When IFS is unset, unquoted $* undergoes word splitting as if IFS=' ', >> and not the expected IFS=$' \t\n'. All the other unqu

Unexpected word splitting on $* when IFS is unset

2017-06-19 Thread Kevin Brodsky
Hi, When IFS is unset, unquoted $* undergoes word splitting as if IFS=' ', and not the expected IFS=$' \t\n'. All the other unquoted mass expansions ($@, array[*], array[@]) are word-split as if IFS=$' \t\n'.For instance: nb_args() { echo $#; } set -- $'a\nb' unset IFS # Expected: 2,