Add a chart comparing Argh to existing parsers about argh HOT 10 OPEN

I've updated the comparison table. argh has the same binary size overhead as pico-args, but takes 13x times more to compile.

Another difference is that argh supports help generation, while pico-args not (intentionally). And pico-args supports --value=5 format and native OS strings (for Windows file paths).

from argh.

I'd want --value=5 to at least be supported as a build feature. There's a certain set of conventions I expect from a Linux command. Not everything follows them, but I hate it when programs don't and being unable to provide them in my own creations is a deal-breaker. They include:

• Supporting -abc as shorthand for -a -b -c (Whether -abc foo is equivalent to -a -b -c foo when -c takes an argument is more negotiable.)
• Supporting --this format for long arguments (GNU-style, not X11-style -this)
• Supporting both --foo=bar and --foo bar (It's useful for avoiding certain kinds of quoting-related footguns or needs to switch to much more advanced constructs when writing shell scripts which pass user-specified sets of arguments.)
• Supporting both -h and --help for help (I have a zsh script which retrofits -h onto GNU coreutils.)
• Not requiring optional arguments to come before positional arguments (eg. alias foo="foo --bar baz"; foo --garg --vorticon)
• Generating --help output that's compatible with the conventions assumed by help2man
• Making an effort to follow existing conventions for command-line argument meanings.
• Allowing later specifications of a non-accumulating argument to override earlier ones. (eg. alias foo="foo --outfile=bar"; foo --outfile=baz)

(As you can see, many of the oddities are affordances for making shell-scripting and aliasing more convenient.)

from argh.

Some context,this tool wasn't written for linux, it was written for Fuchsia which has a very different set of constraints. This is called out in the first line of the README. However, we happen to use it quite happily for linux host-side tools these days. I'm not against adding this support because I would like this library to be maximally useful, but it would need to be under a "linux" feature set.

https://fuchsia.dev/fuchsia-src/development/api/cli

from argh.

Maybe it's going to be a premature opinion, but I feel like argh is the only choice starting from 2020. 👏

What I basically need: I need a prebuilt graph of my subcommands and options (thanks to #[derive]), and then parse command-line arguments accordingly. It should be easy and cheap (buildtime/runtime/binsize). It should have configurable help. Source code of the library should be clear and credible. So you will find it in argh.

from argh.

--foo bar vs. --foo=bar and they have to do with two features of Bourne shell script that become troublesome to get right when you're doing something like this my_script --cmd "foo --arg1 --arg2 bar baz" (or reading a set of arguments from an environment variable).

• Not quoting enough when nesting things like "", '', and $() or using too many or too few escapes, because, to make typing things on the command-line comfortable, each statement needs to have its arguments re-quoted to prevent splitting on whitespace. (ie. No, don't split that argument here either.)
• Having to split some variable contents like --foo --bar according to shell quoting rules at a place of your choosing. (Triggering splitting at a place of your choosing is non-obvious because the approach you see recommended basically involves reconfiguring the parser using things like set -f (disable globbing) and modifying the IFS (Input Field Separator), then triggering a reparse, and then setting them back... and you'd better hope you know all of the things like set -f that need to be set to known values.)

Having access to both --foo bar and --foo=bar allows you to use whichever form is most amenable to hacks such as "Valid contents for --foo never contain spaces" to work around Bourne-family shells not having standardized arrays between them, the shells which do have them (eg. bash, zsh) making them feel very bolted-on, and environment variables having no array type.

from argh.

Thanks so much for doing that @RazrFalcon! Do you mind if I link to your table from the README?

Argument parsing is a multi-dimensional space and I hope people chose the tool that's right for them. We for example chose intentionally to not support the = syntax.

from argh.

@cavedweller am a fan of that choice, not supporting =... more clean.

from argh.

@cavedweller Sure.

@tshepang Looks like a good candidate for a build feature.

from argh.

@ssokolow what are those quoting-related footguns that --for bar (versus --foo=bar) has?

from argh.

Some context,this tool wasn't written for linux, it was written for Fuchsia which has a very different set of constraints. This is called out in the first line of the README.

As of 2022 the README doesn't mention this. Does this mean that argh now properly support Linux/Unix conventions?

from argh.