3 ms·
I disagree on the 2nd point. Flags prevent globbing by the shell and make the help text less clear. Consider a usage line like this: prog <user> [password
by kpcyrd 8y ago
I disagree on the 2nd point. Flags prevent globbing by the shell and make the help text less clear.
Consider a usage line like this:
prog <user> [password]
This tells you which argument is mandatory and which argument is optional in a second, without searching for the help text of --user and --password.
Also, an example like this:
git add <pathspec>...
Tells you that git add accepts multiple paths and you can invoke it with:
git add src/*
What's more important in my opinion is making sure your argument parser can handle values that start with a dash and respects a double dash to stop the option parser.
Consider an interface like this:
prog [--rm] [--name <name>] [args...]
And you invoke it like this:
prog --name --rm -- --name foo
This should result in:
{
"name": "--rm",
"args: ["--name", "foo"]
}
Getting things like this wrong can result in security issues.
- dickeytk 8y agoI may try to expand on this in the article, but it's in there if you read between the lines. There is a difference between something that takes in multiple args of the same type and multiple TYPES of args. I'm arguing against multiple args of different types, not the same. By definition any CLI that accepts variable args is fine here as it's all the same type. The -- is a great point as well. It solves a lot of problems users have but a lot of time people don't even know about it. It solves issues with `heroku run` for example. EDIT: updated to clarify my point
- chriswarbo 8y agoI don't like using arguments for key/value data, e.g. `prog --name foo`. Much better to use env vars like `NAME=foo prog`, since the OS handles the mapping automatically, reading them out is trivial in every language, passing args to subprocesses is easier, etc.