CLI Flag Parsing Conventions
The cluster discusses conventions for command-line argument parsing, including single-dash vs double-dash options, adherence to GNU standards like getopt_long, and suggestions for better libraries such as argparse alternatives or docopt.
Activity Over Time
Top Contributors
Keywords
Sample Comments
It is sad that many new command-line parsing libraries don't follow the GNU rules anymore. They more often use "-long". Then users have to figure out whether this means "--long" or "-l -o -n -g". To make command line even more confusing, multiple tools I have used allow spaces in optional arguments (e.g. "-opt1 arg1 arg2 -opt2", where arg1 and arg2 set two values for -opt1). Every time I see this, I worry if I could be misusing these tools. I wish eve
The lack of double-dash in the stdlib really annoys me. Almost all command line tools use a single dash for single letter arguments (-h) and double-dash for anything longer (--help).
What would make Python better for command line use? Better alternatives to argparse in the standard library?
Am I the only one that thought this was a universal format for describing CLI arguments?
I think they mean why is it sometimes "./foo --help" vs "./foo -h" or "./thing --other=123 --value=456" but sometimes "./thing -o 123 -v 456"
Just go through the docs. They have a ton of single hyphen long opts that aren't a letter with argument.
No, that's how optional flags should work. I mean how specifically -i works. With GNU sed:-lN, --line-length=N, -l N, --line-length NAll work the same, set line length to N.-iSUFFIX --in-place=SUFFIX, -i NEXTARG --in-place NEXTARGDon't all work the same. The argument is only actually taken if it's attached to the flag directly. In the latter two forms, no backup is made.GNU mktemp is similarly annoying, but different, with the --tmpdir flag.-pDIR, --tmpdir=DI
I'd expand on this and say every command line program should support GNU getopt_long() syntax, since this is the most popular syntax for command line interfaces and it saves having to guess the syntax when using a program for the first time. This doesn't mean all programs should use getopt_long(), but they should understand all the syntax that getopt_long() understands, such that someone could reimplement the program's command line interface using getopt_long() and get exactly the
Double dash for long args is a GNUism. One which even they don't adhere to uniformly as evidenced by GCC's options.
Getopt and its brethren in other languages are starting to get long in the tooth. Modern CLI tools need more flexible parsing.