BASH bug?

[hugle]

PP> On Mon, Dec 22, 2003 at 01:43:43AM -0800, hugle wrote:
>> Hello all.
>> I have a little problem in here.
>> Actulay i think, that bash doesn't count good,

PP> If the problem was counting, then it wouldn't be bash anyway -
PP> the 'wc' utility that you are using to count the lines is not part
PP> of the shell, but rather part of the operating system (FreeBSD) -
PP> it's a separate executable, /usr/bin/wc.

>> look:
>> 
>> cat bin/users | wc -l
>>     1877
>> so the file contains 1877 lines
>> 
>> cat bin/users:
>> #!/bin/sh
>> /sbin/ipfw -q delete 2001 >/dev/null 2>&1 &
>> /sbin/ipfw -q add 2001 count ip from 192.168.0.1 to not me in via fxp0 >/dev/null 2>&1 &
PP> [snip]
>> /sbin/ipfw -q delete 2938 >/dev/null 2>&1 &
>> /sbin/ipfw -q add 2938 count ip from not me to 192.168.5.99 out via fxp0 >/dev/null 2>&1 &
>> 
>> so I should have 938 rules in my firewall.
>> 938 * 2=1876 + 1 = 1877 lines in the script (1 rule for delete rule
>> and one for add rule + rule at the top '#!/bin/sh')

PP> Right so far.

>> but when adding this rules to the ipfw ruleset i have:
>> ipfw show 2000-2938 | wc -l
>>      809

PP> Now here's a stupid question: is there a reason that you execute each
PP> of the ipfw commands in the script *in the background* (the & at the
PP> end)?  It is quite possible that when you tell bash to execute 1876 jobs
PP> in the background, and when bash tells the FreeBSD kernel to execute
PP> 1876 jobs at the same time, without waiting for the previous one to
PP> complete, that's just what happens: some of the jobs are executed
PP> *before* the ones preceding them.  What would happen if, say, the 'ipfw
PP> delete 2010' job was delayed sufficiently that the 'ipfw add 2010 ...'
PP> command completes beforehand?  The 'ipfw delete 2010' would remove the
PP> *new* 2010 rule, and you will not have a 2010 rule in your ruleset
PP> afterwards.

PP> So a simple solution: try removing the '&' at the end of each line -
PP> matter of fact, I personally don't see a real reason why it should do
PP> you any good at all; the only thing it *could* do is interfere with the
PP> order of operations so as to actually make the script *not* do what you
PP> want :)
Thanks Peter, that work perfectly!
The reason why i used '&' it that i thought it would make messaegs
like :
Dec 22 15:21:32 perl /kernel: ipfw: Entry 2926 cleared.
Dec 22 15:21:32 perl /kernel: ipfw: Entry 2929 cleared.
Dec 22 15:21:32 perl /kernel: ipfw: Entry 2930 cleared.
Dec 22 15:21:32 perl /kernel: ipfw: Entry 2931 cleared.
Dec 22 15:21:32 perl /kernel: ipfw: Entry 2935 cleared.
Dec 22 15:21:32 perl /kernel: ipfw: Entry 2933 cleared.
won't apper in dmesg. cause ">/dev/null 2>&1' only makes them not to be seen in console (if
I run from console). but then run from cron tab those annoyng messages
apper;(



PP> G'luck,
PP> Peter