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-re
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
$log_file | {
while read line
do
line_num=`expr $line_num + 1`
echo $line_num: $line >> ./out.log
done
}
--
View this message in context:
http://old.nabble.com/bizarre-trap-behavior-while-reading-a-file-tp31242064p31259743.html
Sent from the Gnu - Bash mailing list archive at Nabble.com.
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
bash', it will exit.
>
Thanks for all the answers. I think I understand the problem now. I wonder
though if there is any way to disable default HUP handling int the
subprocess executing the loop?
--
View this message in context:
http://old.nabble.com/bizarre-trap-behavior-while-reading-a-file-t
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
I probably receives
SIGHUP but I am not sure about the rules of process naming: why
instead of cat?
--
View this message in context:
http://old.nabble.com/bizarre-trap-behavior-while-reading-a-file-tp31242064p31258525.html
Sent from the Gnu - Bash mailing list archive at Nabble.com.
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
on
4.1.7(1)-release (x86_64-redhat-linux-gnu).
It is even more bizarre that you could not reproduce it. I can reproduce it
at will...
--
View this message in context:
http://old.nabble.com/bizarre-trap-behavior-while-reading-a-file-tp31242064p31257975.html
Sent from the Gnu - Bash mailing list archive at Nabble.com.
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
t; $log_file
wc -l out.log
exit 0
--
View this message in context:
http://old.nabble.com/bizarre-trap-behavior-while-reading-a-file-tp31242064p31242064.html
Sent from the Gnu - Bash mailing list archive at Nabble.com.
16 matches
Mail list logo