Hey Seth,

I checked out that commit, and it fixes the error, but there is also no output when I run it.

I modified the new version with some print statements to trace what's going on:

# exec-test.bro
@load ./exec

event bro_init()
        print "hello";
        Exec::run("date", function(r: Exec::Result) {
                print "test";
                if ( ! r?$stdout )
                        print "nothing?!?";

                for ( i in r$stdout )
                        print r$stdout[i];
                        print r$stdout;

# exec.bro
function run(cmd: string, cb: function(r: Result))
        print "run";
        local tmpfile = "/tmp/bro-exec-" + unique_id("");
        system(fmt("touch %s_done", tmpfile));
        system(fmt("touch %s_stdout", tmpfile));
        system(fmt("touch %s_stderr", tmpfile));
        # Sleep for 1 sec before writing to the done file to avoid race conditions
        # This makes sure that all of the data is read from
        system(fmt("%s 2>>%s_stderr 1>> %s_stdout; echo \"exit_code:${?}\" > %s_done; sleep 1; echo \"done\" >> %s_done", cmd, tmpfile, tmpfile, tmpfile, tmpfile));

        results[tmpfile] = [];
        callbacks[tmpfile] = cb;

        schedule 1msec { start_watching_files(tmpfile) };
        print "run finished";
        print cmd;
        print results;

When I run that, I get the following output:
$ bro -r test.pcap exec-test.bro
run finished
[/tmp/bro-exec-CRmEOhHjsgk] = [exit_code=0, stdout=<uninitialized>, stderr=<uninitialized>]

Something is happening, though:
$ ls /tmp/
bro-exec-Uvha209VjSk_done  bro-exec-Uvha209VjSk_stderr  bro-exec-Uvha209VjSk_stdout
$ cat /tmp/bro-exec-Uvha209VjSk_stdout
Thu Feb 21 2013

But, that data never makes it to the output in the bro script.

I'm curious why "test" never gets printed.

On Thu, Feb 21, 2013 at 3:30 PM, Seth Hall <seth@icir.org> wrote:

On Feb 21, 2013, at 3:16 PM, Chris Crawford <christopher.p.crawford@gmail.com> wrote:

> Hey Seth,
> Having this type of functionality would be awesome!  It would "unlock" bro to the point where we would only be limited by our imaginations with what we could make bro do.
> I know you mentioned that the current stuff is broken on github, but I gave it a try anyways (I modified the command in exec-test.bro to the date command):
> $ bro -r test.pcap exec-test.bro
> entering the async whatever
> yay!
> {
> [/tmp/bro-exec-4N1gxc3hF32] = [Thu Feb 21 2013]
> }
> bro: bro-2.1/src/Trigger.cc:227: bool Trigger::Eval(): Assertion `frame->GetCall()' failed.
> Aborted
> So close, and yet so far.

Yep, that's the bug.  Try checking out the other commit that I suggested.  That should make it work.

Additionally I already have a full module named ActiveHTTP wrapped around it (about 100 lines of code) that uses the curl command line client internally (yes, hacky) but present a very nice and clean API to users.  You currently get the body of the response, the response code, the response message, and all of the headers the server returned.

This sort of opens the door to all kinds of crazy stuff though. Someone (you know who you are!) already mentioned the idea of doing an NMAP wrapper so that people could start NMAP scans and get results back into Bro really easily.

> I'm assuming that this is the bug that you mentioned Bro 2.2 will fix.  When is Bro 2.2 expected to be released?

We aren't quite sure yet, we're furiously working on several big features now.  We're


Seth Hall
International Computer Science Institute
(Bro) because everyone has a network