Greetings, Buchbinder, Barry (NIH/NIAID) [E]!
> Just to complete this topic ...
> This gets rid of all the fork-execs in the inner loop except
> for sleep. Instead of comparing file contents, it uses
> the test builtin to compare time stamps.
I /never ever/ rely on timestamps, except for casual
Just to complete this topic ...
This gets rid of all the fork-execs in the inner loop except
for sleep. Instead of comparing file contents, it uses
the test builtin to compare time stamps.
#!/bin/dash
FILE_TO_CHECK=/mypath/style.less
COMPARE_FILE=/mypath/compare_file.tm
On 05/31/2012 11:42 AM, Jordan wrote:
> Hi folks,
>
> I've written a shell script running under CygWin, the purpose of which is to
> monitor a file for changes. If the MD5 hash fails to match the previous hash,
> it
> will execute a command to process the file. I used a 1-second delay between
On 06/01/2012 03:20 AM, Adam Dinwoodie wrote:
> Buchbinder, Barry wrote:
>> You might try changing
>> [[ condition ]]
>> to
>> [ condition ]
>> Perhaps single brackets use memory differently than double brackets.
>
> They do: [[ condition ]] is interpreted by the shell; [ condition ] forks
On May 31 17:42, Jordan wrote:
> Hi folks,
>
> I've written a shell script running under CygWin, the purpose of which is to
> monitor a file for changes. If the MD5 hash fails to match the previous hash,
> it
> will execute a command to process the file. I used a 1-second delay between
> check
AZ 9901 wrote:
> So some things to avoid while (bash)scripting under Cygwin to limit
> BLODA effect :
> - | : pipe stdout --> stdin
> - $(...) : subshell fork
> - `...` : same as before, subshell fork
> - [ condition ] : prefer [[ condition ]] construction
> - anything else ?
By my understanding o
2012/6/1 AZ 9901:
> 2012/6/1 Adam Dinwoodie:
>> Buchbinder, Barry wrote:
>>> You might try changing
>>> [[ condition ]]
>>> to
>>> [ condition ]
>>> Perhaps single brackets use memory differently than double brackets.
>>
>> They do: [[ condition ]] is interpreted by the shell; [ condition ]
2012/6/1 Adam Dinwoodie:
> Buchbinder, Barry wrote:
>> You might try changing
>> [[ condition ]]
>> to
>> [ condition ]
>> Perhaps single brackets use memory differently than double brackets.
>
> They do: [[ condition ]] is interpreted by the shell; [ condition ] forks to
> call /usr/bin/[.
I will not address the memory management problem, if there is one here.
I am addressing your method of determing a difference.
No offense, but it seems extremely inefficient, and the larger the file you are
computnig the md5sum on the more inefficient.
Why not use the file system's "modified"
Jordan yahoo.com> writes:
> This works great for several hours, but then gives an "out
> of memory" error and actually brings Windows 7 to its knees.
> I can provide the exact memory error if
> requested
I reproduced it again. The error messages are as follows:
./myscript.sh: line 32: /usr/bi
2012/5/31 Jordan :
> AZ 9901 :
>>
>> Make an infinite loop with no fork, and look at the memory usage.
>> Then, make an infinite loop with one fork and look at the memory
>>
>> I really hope a solution will be found one day
>>
>
> Argh! And I really like CygWin, so I was hoping to learn that this
AZ 9901 gmail.com> writes:
>
> Make an infinite loop with no fork, and look at the memory usage.
> Then, make an infinite loop with one fork and look at the memory
>
> I really hope a solution will be found one day
>
Argh! And I really like CygWin, so I was hoping to learn that this is
reso
2012/5/31 Eliot Moss :
>> 1. Does "fewer forks" mean that some forks are still occurring, thus the
>> same
>> memory crash will still happen, but not right away? Just delaying the
>> inevitable, for longer than my original script does?
>
>
> I think so, assuming the problem is that forks are not
The following are just ideas - totally untested.
You might try changing
[[ condition ]]
to
[ condition ]
Perhaps single brackets use memory differently than double brackets.
If that doesn't work, try changing
#!/bin/sh
(which calls bash) to
#!/bin/dash
You will have to have retain
1. Does "fewer forks" mean that some forks are still occurring, thus the same
memory crash will still happen, but not right away? Just delaying the
inevitable, for longer than my original script does?
I think so, assuming the problem is that forks are not getting fully reclaimed.
2. What is
Thrall, Bryan flightsafety.com> writes:
>
> AZ 9901 wrote on 2012-05-31:
> > 2012/5/31 Jordan :
> > Then, when (bash) scripting under Cygwin, you must take care to avoid
> > forking as much as possible.
> >
> > You could try to improve the "sleep 1" loop with the following one :
> >
> > while
AZ 9901 wrote on 2012-05-31:
> 2012/5/31 Jordan :
> Then, when (bash) scripting under Cygwin, you must take care to avoid
> forking as much as possible.
>
> You could try to improve the "sleep 1" loop with the following one :
>
> while md5sum $FILE_TO_CHECK | cut -d " " -f1 | grep -q "^$MD5PRINT
2012/5/31 Jordan :
> I am just wondering why the loops here are consuming increasing amounts of
> memory over time? I'm assigning new MD5 values into existing variables over
> and
> over, not allocating new variables for each MD5 assignment. (Right??) Is 1
> second perhaps too short a delay... do
18 matches
Mail list logo
