Customize Argbash messages

[matejak]

Some interaction with the user could be improved and made customizable, for instance:

• error messages when supplied positional arguments don't match the interface,
• error message when the argument type doesn't match.

[matejak]

Possibility of customizing error messages is not there yet (I have to think it through and through), but the current positional args error messages are improved based on your input.

[edannenberg]

Much better already, thanks.

As for customizing I still think an approach as I outlined in #3 (last section) should leave no wishes when it comes to customizing.

So instead of:

test ${#_positionals[@]} -lt 1 && _PRINT_HELP=yes die "Not enough positional arguments - we require at least 1 (namely: $_required_args_string), but got only ${#_positionals[@]}." 1

...the following would allow full customization:

test ${#_positionals[@]} -lt 1 && { _missing_args=$_required_args_string; _min_args_count=1; }

# default error message output
default_print_error() {
_PRINT_HELP=yes die "Not enough positional arguments - we require at least $_min_args_count (namely: $_missing_args), but got only ${#_positionals[@]}." 1
}

# only use default error message if print_error is not defined already, this allows
# a parent script to take over by defining it's own print_error function
# useful data for output should be provided in vars like _missing_args in this example
declare -f -F print_error || print_error=default_print_error

# display error
[[ ${_arg_help} != on && -n _missing_args ]] && print_error

The same principle could be applied to print_help() and die(), basically all functions a user may want to override.

[matejak]

Yes, I agree with you. My vision is to provide a default that works for most people, but allow customization for others. It will take me some time to get there and to get it right, I would like to avoid changing the API in the case that the first design will be proven clumsy.

[edannenberg]

Hello Matěj,

thanks for all your work, nice to see how argbash has matured in the last years. The diy mode helped a lot already but there still is a big blocker as we can't access the default help output from there.

I would like to avoid changing the API in the case that the first design will be proven clumsy.

Agreed, but at this point I wouldn't mind if the API is marked as alpha/beta and subject to change. As is I'm kinda stuck with modified argbash files I can't easily rebuild.

[matejak]

OK, I will look into it. Looks like that a support for overrides in current functions could be a way forward.