Does getopts not accept optional arguments for an option using double colons (e.g. using shortopts="t::")?

  • For multi-word arguments, use quotes: ./script.sh -t "three word argument" and remember that it is then one string with spaces in variable OPTARG that might need splitting depending on your use case.
    – FelixJN
    Dec 19, 2021 at 21:03
  • getopt does; getopts with an s does not. Beware options with optional arguments - how will the system decide whether a following argument is the optional value, or a new, separate argument? That's probably why getopts skipped it. I consider it a bug, not a feature. Oct 6, 2022 at 13:50
  • @PaulHodges, the way the various getopt() implementations treat optional option-args is by taking everything after the option character in the same command line argument as the option-arg. So if -a takes an optional option-arg, -abc is -a with the opt-arg bc, while -a bc is -a without an opt-arg (or with the empty string), plus bc as a regular non-option argument. That gives a well-defined result and allows passing arbitrary strings as optional opt-args, but annoyingly different from how mandatory opt-args work, with both -abc and -a bc meaning -a with the opt-arg bc.
    – ilkkachu
    Mar 8, 2023 at 21:06

1 Answer 1


No, Bash's getopts doesn't support optional option-arguments.

There's nothing in the manual to indicate that it would, it only says

if a character is followed by a colon, the option is expected to have an argument, which should be separated from it by whitespace.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .