On Tue, Feb 26, 2008 at 12:44 AM, Danek Duvall <[EMAIL PROTECTED]> wrote: > On Mon, Feb 25, 2008 at 09:39:58PM -0600, Shawn Walker wrote: > > > I'm working on bug 244 ( > http://defect.opensolaris.org/bz/show_bug.cgi?id=244 ). > > I want to fix this by introducing a real parser for the filters, rather > than relying on this bastardized version of python. I'm using PLY for the > solaris.py replacement, but the OSR for that hasn't gone through yet, so > I haven't bothered integrating its use that deeply in the IPS codebase.
Can I still make an interim fix then or should I just abandon this change? > > For example, suppose that we have something tagged as such: > > > > file path=/usr/bin/hostname arch=386 version=1.0 > > > > Should arch=386 & version=1 match the first line? > > > > Or, should the first line only match if arch=386 & version=1.0? > > The latter. All attribute values are considered strings; the reason that > numerics don't work right now is because Python identifiers can't start > with a number. Okay, well I have it working already and I have a few test cases for it working as simple strings. Is it worth posting for review and integration then? > This means that parsing an attribute like "3ufw355" will be tough, since > it's neither a number nor an identifier. Which is one reason that we may > not be able to use the Python parser to do this. That would make sense. > I'm planning on extending the language to allow for substring matches, or > something similar, but again, that'll be tons easier with a lower-level > parser. I definitely can agree with that. Cheers, -- Shawn Walker, Software and Systems Analyst http://binarycrusader.blogspot.com/ "To err is human -- and to blame it on a computer is even more so." - Robert Orben _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
