Cool. I pulled the most recent code from github. It cleans up /tmp, the code looks cleaner -- with more when statements -- but it also causes bro to consume 100% CPU and the only way I can kill bro is by doing a Ctrl-Z and then a kill -9. I never get output from the command I add to Exec::run, so I added some print statements to try to trace where things go off the tracks:
1 @load ./exec
4 event bro_init()
6 print "hello";
7 when ( local result = Exec::run([$cmd="ls /"]) )
9 print "it ran?!?";
10 if ( result?$stdout )
11 print result$stdout;
12 if ( result?$files )
13 print result$files;
140 function run(cmd: Command): Result
142 print "hi";
Then, when I run the following:
$ bro /usr/local/bro-2.1/share/bro/policy/frameworks/communication/listen.bro exec-test.bro
So, it looks like bro gets hung up before it can get into Exec::run.
You don't have to do that check if you know your script will have something on stdout. I may even make stdout an empty vector by default (as opposed to null). I can see that argument making sense.
On Feb 22, 2013, at 11:59 AM, Chris Crawford <firstname.lastname@example.org> wrote:
> This got me wondering -- why would exec-test.bro ever have a case where (! r?$stdout) is true, when I have a program that absolutely returns output every time it's run? (And then print out "nothing?!?")
You're running old code. :) I may not have finished taking care of that yet in the version you're running. Hopefully this will be in Bro's master branch soon but using when statements and just generally being much nicer.
> system(fmt("rm %s_done", tmpfile));
> system(fmt("rm %s_stdout", tmpfile));
> system(fmt("rm %s_stderr", tmpfile));
> I'm just not sure where it should go.
International Computer Science Institute
(Bro) because everyone has a network