Chet Ramey wrote:
>
> You might have better luck moving the trap command inside the { ... },
> before the while loop.
>
Yes. I realized that after a bit of testing :). Thanks
--
View this message in context:
http://old.nabble.com/bizarre-trap-behavior-while-reading-a-file-tp31242064p31267546
Chet Ramey wrote:
>
>
> Sure. Trap it to SIG_IGN: `trap "" SIGHUP'.
>
>
OK. Thanks everybody for their input. Really appreciate all the answers. I
modified the first loop as follows to get the subshell to ignore HUP signal:
trap "" HUP; cat $log_file | {
while read line
do
Chet Ramey wrote:
>
> There is a bash process that is forked to execute the `while read ...'
> in the first pipeline loop. It has to hang around the whole time, so it
> can run the while loop and exit with the correct status. If you send it
> a SIGHUP with `killall bash', it will exit.
>
Tha
Interesting...
I used kill -HUP instead of killall -HUP and it works
without interrupting the first loop. I also noticed 2 processes running when
the first loop is iterating but only 1 when the second loop is iterating:
$ ps -ef |grep
bla 3711 2671 0 09:50 pts/000:00:00 /bin/bash ./
bl
Chet Ramey wrote:
>
> On 3/25/11 5:25 PM, tytus64 wrote:
>
> You don't say anything about what version of bash you're using or what OS
> you're on, but I couldn't reproduce it.
>
>
>
I am running Fedora release 13 (Goddard) with GNU bash, versi
I started execution of the following script and and repeatedly sent a SIGHUP
to it from another shell. If SIGHUP is received within the first while loop
the loop terminates with "wc -l" printing fewer than 4158 lines. If SIGHUP
is received within the second while loop the loop still continues and
