Required param default error

[Adi Unnithan]

First, this is a really great utility! Thanks so much for creating it.

I was wondering, do you have plans to support a default error for params that are required? Currently I have to do like this. Was wondering if those required param checks could be built in, and if you have plans for that.

eval "$(getoptions parser_definition parse "$0")" 
parse "$@"                         
               
[[ -z "${APPNAME-}" ]] && die "Missing required parameter: --appsvc-name"
[[ -z "${FILEPATH-}" ]] && die "Missing required parameter: --upload-filepath"

[Koichi Nakashima]

Hi,

Is it this feature that you are talking about?

examples/basic.sh

$ examples/basic.sh --help
Usage: basic.sh [options...] [arguments...]

getoptions basic example

Options:
  -a                          message a
  -b                          message b
  -f, +f, --{no-}flag         expands to --flag and --no-flag
  -v,     --verbose           e.g. -vvv is verbose level 3
  -p,     --param PARAM       accepts --param value / --param=value
  -n,     --number NUMBER     accepts only a number value
  -o,     --option[=OPTION]   accepts -ovalue / --option=value
  -h,     --help
          --version

$ examples/basic.sh --param
Requires an argument: --param

[Adi Unnithan]

Not quite - if I leave out --param completely, I want it to throw an error. Currently it doesn't do that for me, but I could be missing something.

[Koichi Nakashima]

I agree with the following opinions.

https://docs.python.org/3/library/optparse.html#what-are-options-for

What are options for?

Options are used to provide extra information to tune or customize the execution of a program. In case it wasn’t clear, options are usually optional. A program should be able to run just fine with no options whatsoever. (Pick a random program from the Unix or GNU toolsets. Can it run without any options at all and still make sense? The main exceptions are find, tar, and dd—all of which are mutant oddballs that have been rightly criticized for their non-standard syntax and confusing interfaces.)

Lots of people want their programs to have “required options”. Think about it. If it’s required, then it’s not optional! If there is a piece of information that your program absolutely requires in order to run successfully, that’s what positional arguments are for.

For this reason, I intentionally did not consider this feature.

I just thought about it a bit and couldn't come up with a way to implement it (without increasing the amount of code significantly). I probably won't add it. I think it's better to make your current code or it a function.

As an alternative, you can improve getoptions by yourself or create additional modules.

For example, let's add the following code to the end of example/basic.sh. You will find that you can easily examine the attributes. You can add your own attributes and extend it freely with those attributes.

examples/basic.sh

ext() {
	setup() { echo "setup" "$@"; }
	msg() { echo "msg" "$@"; }
	flag() { echo "flag" "$@"; }
	param() { echo "param" "$@"; }
	option() { echo "option" "$@"; }
	disp() { echo "disp" "$@"; }
	"$@"
}
ext parser_definition parse "$0"

output

setup REST plus:true help:usage abbr:true -- Usage: basic.sh [options...] [arguments...]
msg -- getoptions basic example
msg -- Options:
flag FLAG_A -a require:true -- message a
flag FLAG_B -b -- message b
flag FLAG_F -f +f --{no-}flag -- expands to --flag and --no-flag
flag VERBOSE -v --verbose counter:true init:=0 -- e.g. -vvv is verbose level 3
param PARAM -p --param pattern:foo | bar -- accepts --param value / --param=value
param NUMBER -n --number validate:number -- accepts only a number value
option OPTION -o --option on:default -- accepts -ovalue / --option=value
disp :usage -h --help
disp VERSION --version