> On Dec 7, 2017, at 5:22 PM, Johanna Amann <joha...@corelight.com> wrote:
> Indeed, that is my thought. This seems like a job for broker, instead of > trying to somehow force this into a complex ascii-representation. > > Note that this is just a limitation of the config reader - the rest of the > config framework (that does not deal with file reading) does not care what > you throw at it and will happily accept tables, etc. So if you get Broker to > give you a table you should be able to just use the calls for setting options > with that table afterwards. > > Johanna Cool.. so you figure something like a python script to load/organize your data from whatever upstream source you have, then just call Option::set using broker? I think the ascii representation of data structures would still help in a few places.. bro is in a weird place right now where we have json and 'print' that can output an ascii representation of almost any data structure, but what it outputs is not always valid bro code that can be parsed in the other direction. Like, const foo: table[subnet] of set[port] = { [192.168.0.0/24] = set(22/tcp) }; Gets turned into { [192.168.0.0/24] = { 22/tcp } } But the bro parser doesn't parse {...} as a set. and const foo: table[subnet] of vector of port = { [192.168.0.0/24] = vector(22/tcp) }; Gets turned into { [192.168.0.0/24] = [22/tcp] } But trying to parse that crashes: internal error in ././trybro.bro, line 2: missing aggregate in ListExpr::InitVal (22/tcp) — Justin Azoff _______________________________________________ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev