In a number of our tools, I’ve written rudimentary command parser hacks using getopt and some creative ARGV processing. And this almost always led to something more complex and harder to develop/maintain.
For something else we are looking at, I’ve been exploring “compilers”. Basically, define a grammar to do something, then do it. Keep the grammar consistent, simple, and easy to manage.
Turns out that this maps far better into our target code than I would have thought. Also maps (perfectly) into our config code. And our monitoring code. Etc. That is, we want to create little “programs” that are interpreted to perform the function. “Programs” could be one liners, or more complex beasts (if needed).
The rationale for this is in part that I want to get out of the business of writing parsers. They are annoying, complex, and often I get version drift between the thing put into the GUI and the thing in the CLI, or I start some backward bending crap to map what we do in the CLI into the GUI. What if the code between them is common. Developed once, with all the tests embedded.
Yeah, looking to make this easier for us. Most of our utilities are written in Perl, and there are a pair of (very powerful) modules: Parse::RecDescent and Parse::Eyapp, that look like they would handle pretty much everything we need to do for this subset of tasks.
Specifically, I was hand coding a syntax tree using a mental image of the grammar I wanted (at a high level, not the level of detail that was needed). This is fine for very simple tools with few options. Starts getting to be an issue once you need to do complex things with your simple tools.
So I am looking at these tools. In the short run, I have a working example prototype I can build from for Parse::RecDescent that I can probably turn into what I need fairly quickly. On the other hand, I am thinking about data flow programming and looking to play with some tools to try out some ideas. It looks like LALR parsers may be more the way to go there (P::Eyapp) versus the LL parsers (P:RD). That and I seriously want to play with LLVM. That part is for later, right now I’ve got the practical stuff to work on.