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
On Tue, Mar 29, 2011 at 08:02:17AM -0400, Steven W. Orr wrote:
> Is there a difference between
>
> while read line < file
> do
> stuff
> done
>
> vs
>
> while read line
> do
> stuff
> done < file
Yes. It's a huge difference. In the first one, the file is re-opened
by read every time t
On 3/29/2011 2:33 AM, Mart Frauenlob wrote:
On 28.03.2011 18:03, tytus64 wrote:
[...]
trap "" HUP; cat $log_file | {
while read line
[...]
useless use of cat!
while read ... < file
no need for a subshell actually (introducted by the pipe).
I'm a big opponent of useless cats, but I ha
On 28.03.2011 18:03, tytus64 wrote:
[...]
trap "" HUP; cat $log_file | {
while read line
[...]
useless use of cat!
while read ... < file
no need for a subshell actually (introducted by the pipe).
On 3/28/11 12:03 PM, tytus64 wrote:
> 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
> line_num=`expr $line_num + 1
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
On 3/28/11 11:39 AM, tytus64 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
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
On 3/28/11 9:59 AM, tytus64 wrote:
>
> 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:
There is a bash process that
On Mon, Mar 28, 2011 at 06:59:23AM -0700, tytus64 wrote:
>
> 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:
>
> $ p
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
On 3/28/11 9:12 AM, tytus64 wrote:
>
>
> 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, vers
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, version
4.1.7(1)-release (x86_64-redhat-linux-gnu).
On Fri, Mar 25, 2011 at 02:25:35PM -0700, tytus64 wrote:
> while read line
> do
> line_num=`expr $line_num + 1`
> echo $line_num: $line >> ./out.log
> done < $log_file
Although it's not directly related to your question, I feel obliged
to point out that you can increment a variable without
On 3/25/11 5:25 PM, tytus64 wrote:
>
> 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 se
15 matches
Mail list logo