That was interesting to read and certainly a different approach to solving a problem, but the biggest question I had in my mind while reading the article was "is it really necessary to create all this complexity --- and how does it compare to the traditional getopt()?"<p>I've used getopt() many times, even implemented its functionality for fun, and parsing commandline arguments has never been something I thought was particularly difficult or complex.
I ended up writing a blog post on how to handle CP arguments a while back. I started coding before really thinking about it -- I mean, it's CP, how hard could it be (famous last words)?<p><a href="http://blog.typeobject.com/thinking-out-loud-file-copy-tool-arguments" rel="nofollow">http://blog.typeobject.com/thinking-out-loud-file-copy-tool-...</a><p>It turns out the arguments to CP are really tough to reason about if you just naively dive into it. The approach in this article is much better than mine. It feels like I was fumbling around in the dark.<p>If you're interested in seeing my implementation (it's buggy, but handles most cases), it can be found at:<p><a href="https://github.com/hpc/dcp/blob/master/src/handle_args.c" rel="nofollow">https://github.com/hpc/dcp/blob/master/src/handle_args.c</a><p>The entry point to handle_args.c is DCOPY_parse_path_args, which is called by the main() in:<p><a href="https://github.com/hpc/dcp/blob/master/src/dcp.c" rel="nofollow">https://github.com/hpc/dcp/blob/master/src/dcp.c</a>
Why write an FSM and backtracking explicitly? Use parser combinators, they basically do the same thing, just express it in a clearer, grammar-friendly way: <a href="http://theorangeduck.com/page/you-could-have-invented-parser-combinators" rel="nofollow">http://theorangeduck.com/page/you-could-have-invented-parser...</a>