Hacker News new | past | comments | ask | show | jobs | submit login

Most cli parsers don't fully support the author's suggested model because it means you can't parse argv without knowing the flags in advance.

For example, the author suggests that a cli parser should be able to understand these two as the same thing:

    program -abco output.txt
    program -abcooutput.txt
That's only doable if by the time you're parsing argv, you already know `-a`, `-b`, and `-c` don't take a value, and `-o` does take a value.

But this is a pain. All it gets you is the ability to save one space character, in exchange for a much complex argv-parsing process. The `-abco output.txt` form can be parsed without such additional context, and is already a pretty nice user interface.

For those of us who aren't working on ls(1), there's no shame in having a less-sexy but easier-to-build-and-debug cli interface.




But every single command line parser I have ever used (and I have used many over the past 25 years in many programming languages) does in fact know before parsing that a b and c don't take a value and o does: accepting the grammar for the flags and then parsing them in this way is like the only job of the parser?


I suppose the only reason why you wouldn't want to have a centralized description of the command line grammar is if you're using flags which alter the set of acceptable flags. Like e.g. if you put all git subcommands into one single executable - the combinations and meanings of commandline flags would become absurdly complicated.


This is usually handled by adding support for that sort of syntax to the parsing library. The result is typically not complicated: you have a parser for the global options, then, if using subcommands, in effect a map of subcommand name to parser for options for that command.


Some programs may allow for plugins which can have their own options. But you may want to provide an option for where to load the plugins from.


Why would someone ever want to use the second syntax? (Genuine question, not rhetorical!)

It seems using = for optional option arguments is only allowed with long form. Why is that? Wouldn't it be nicer to be able to write "program -c=blue" rather than "program -cblue"?


The second syntax when you want to ask a program to pass an argument to another program. Having to pass 2 arguments is a lot more annoying since you'd often then have to prefix each one.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: