Should Shell Functions Use Positional Arguments or Named Options?

The best interface depends on who calls the function. Internal helper functions can reasonably use a fixed order of mandatory arguments, especially when they are only called from a small amount of code. Functions used interactively should have sensible defaults and readable options.

Your current minimum-count check also makes the vault-user argument mandatory even though the function supports leaving it empty. That is a sign the interface could be simplified. You could accept the parameter name as the required argument, then parse optional flags afterward, or make the vault user an option with no required placeholder.

The empty string is not inherently wrong, but it is a poor sentinel when an omitted argument can express the same thing. An empty string might be a meaningful value, so it is better to distinguish “not supplied” from “supplied but empty.”

Put required positional arguments first and optional positional arguments last, or switch to named options once there are several optional values. For example, the parameter name could be required, while the vault user could be optional and default to an environment variable or the normal AWS credential chain.

For a larger command-style interface, use a standard option parser rather than hand-rolling every case. getopts is built into Bash for short options; external getopt or another language’s option library may be more convenient when you need long options and more complex validation.

One possible shape is:

run_aws_ssm_get_parameter [--debug] [--vault-user NAME] PARAMETER_NAME [AWS_OPTIONS...]

That keeps the required data obvious, makes debugging a switch instead of a Boolean string, and leaves room to add options later without breaking every existing call.

A useful starting rule is that positional arguments represent the main data the command operates on, while options control behavior or provide optional configuration. In this case, the parameter name is a good positional argument, while debug and the vault-user choice fit better as options.

For a function intended to be called directly by people, explicit options are usually easier to understand and safer to extend. Use Bash’s getopts for short options, or a small manual parser/getopt-based parser if you need long options such as --parameter-name. Also consider using --debug and --no-debug rather than requiring users to write true or false.