On 09/01/2010, at 2:50 AM, Xyne wrote:
What was the problem with that from Sebastian which was discussed
earlier on the mailing lists, IRCs ? How does it know more ?
I don't know. I wrote this because I needed a PKGBUILD parser in Perl
for Bauerbill. Maybe it's better, maybe it's worse. I posted it here
in
case someone finds it useful per se, or wishes to take any of the
ideas
from it and use them to iimprove other parsers.
It is quite a clever idea. I haven't seen this approach before. I
haven't looked at it thoroughly, but it looks like you're simply
sourcing the PKGBUILD with some trickery not to execute the code. Why
then the need for further parsing? Does `set` produce "raw" bash, e.g.
'source=("https://localhost/$pkgname.tgz";)'? It seems like bash should
be able to do it itself. If that were the case, the parser would be
extremely reliable (definitely more so than mine). There are still
some "safety" issues involved, although maybe not for your purposes.
One major thing is infinite loops - there's no way to break them. I'm
sure this parser will be very useful when such things aren't an issue.
Hmmm, after briefly reviewing the messages, I can mention that my
parser:
* doesn't depent on Yacc/Lex
* supports split packages already
* handles multiline assignments
* supports interpolation and string substitutions
For the record pkgparse does support split packages and word
substitutions (though it's primitive atm, i.e. only $foo works,
modifiers like ${foo##bar} don't). The major problem is with multiline
assignments, but once that get's fixed, most PKGBUILDs should be parse-
able. It probably won't depend on yacc/lex anymore either, but it will
depend on Lemon/Ragel, as that's the direction it seems to be
going :P. It's a compile-time dependency though, so it's not really a
reason not to use it. To use it in perl you'd have to make perl
bindings, which would require compilation anyway.
