mask
mask copied to clipboard
jacobdeichert
Let user specify default/fallback value for named flags
I want to specify parameters list and default for option.
For instance. When make command "formatter" from csv to json or tsv, with default no-convert,I want to specify following:
## formatter
**OPTIONS**
* target
* flags: -t --target
* type: string
* desc: Which port to serve on
* list: csv, json, tsv
* default: csv
I agree with @ogata-k . I'd even extend this to more complex types (e.g. dicts) and phasing in defaulting for both categories, optional/positional parameters. In line with what py argparse [1] does. argparse could be inspiration for more features I sense.
[1] https://docs.python.org/3/library/argparse.html#argparse.ArgumentParser.add_argument
A default: something flag value is easy to support.
As a workaround for now, in my readme example I used a bash fallback value like this:
PORT=${port:-8080} # Set a fallback port if flag is not supplied
So whatever scripting language you're using, you can easily check if the flag is unset and use your fallback for now.
A |default: something| flag value is easy to support.
As a workaround for now, in my readme example I used a bash fallback value like this:
PORT=${port:-8080} # Set a fallback port if flag is not supplied
So whatever scripting language you're using, you can easily check if the flag is unset and use your fallback for now.
Yes sure, for bash moreover, one can:
set -eEu
[...]
To prevent unset params.
Still native mask feature wouldn't harm I sense.
So whatever scripting language you're using, you can easily check if the flag is unset and use your fallback for now.
A default value is convenient when you don't remember how to manipular environment variable with other languages, and some language like Java is hard to export environment.
I'll reopen this since it does seem useful as a feature. Specifying a default value for a flag lets the user easily see what the fallback value is if they don't supply one.
It's a three line change, why even discuss this?
Just because it's a quick change (plus writing tests, documentation) doesn't automatically mean that it should be something we add. Opening an issue for proposing & discussing new features is preferred and it lets me gauge how much interest there is. In this case, there's definitely interest.