Hacker News Reader

Comment by idank | Hacker News Reader

The regex is already getting out of hand ;) https://gist.github.com/idank/6382427

At some point I wanted to convert it to a DFA because I thought it will give me more control and flexibility and be more maintainable over time. The thing to look out for is not make it too permissive so it starts catching things that aren't really options.

View on HN

It's funny that a similar tool to your service can be used to build it! http://www.debuggex.com/

The occasional tool, like find, is beyond the capabilities of a DFA, because it's based on a context free grammar (e.g., it counts parentheses).

This regex is the one I used to extract options from man pages, not to parse the command line (which is simply a wrapper around Python's shlex).

I see. I started doing almost the exact same thing at one time. My goal was to create autocomplete rules. I think I used the output from the tool's --help or -? rather than manpages, and I would have been using awk and sed, since I never learned Python.

Bash autocomplete specifications are messy, but you can sidestep a lot of the mess. You're allowed to run an arbitrary command to generate the completion list. I was envisioning some kind of standard option grammar that the autocomplete program would interpret for a given tool. The grammar would be partly generated automatically, but would likely need hand-tuning.

True for official regular expressions, but not for the ones used in most programming languages. http://nikic.github.io/2012/06/15/The-true-power-of-regular-...

True. Perl-style regexes have grown capabilities far beyond regexes in formal language theory. Note that I was referring to DFAs.

Reply on news.ycombinator.com