Well, quite a small note on getopts

And so, we want to parse command line parameters in our script, and we want to take into account

• Options without arguments
• Options with arguments
• Check for missing argument
• Check for unknown options
• Check for missing parameters
• Design this part of the script as a function.

And now you have the truest way to which I could come

#!/bin/bash function check_arg(){ if [[ $2 == -* ]]; then echo "Option $1 requires an argument" >&2 exit 1 fi } function parse_param() { if [ -z "$1" ];then echo "Empty list of options" >&2 exit 1 fi while getopts ":np:" opt; do case $opt in p) check_arg "-p" "$OPTARG" echo "-p(param) was triggered, Parameter: '$OPTARG'" ;; n) echo "-n(no param) was triggered" ;; \?) echo "Invalid option: -$OPTARG" >&2 exit 1 ;; :) echo "Option -$OPTARG requires an argument (getopts)" >&2 exit 1 ;; esac done } parse_param "$@" 

And here is an example of its use

 [bash]$ ./test.sh Empty list of option [bash]$ ./test.sh -m Invalid option: -m [bash]$ ./test.sh -n -n(no param) was triggered [bash]$ ./test.sh -n -p -n(no param) was triggered Option -p requires an argument (getopts) [bash]$ ./test.sh -p -n Option -p requires an argument [bash]$ ./test.sh -p"1 2 3" -p(param) was triggered, Parameter: '1 2 3' 

Why did I write all this? After all, it is probably all on the Internet has long been painted. I'll explain now. While I was going to this simple implementation, I got up on the rake of using getopts many times in the context in which I needed. Therefore, I would like to describe below the rakes to which I got up along the way, and which led me, I hope, on the right path of using getopts.

Getopts in function

Errors can be concluded in the way you pass arguments to this function, for example, two wrong ways

 parse_param $1 $2 $3 parse_param "$1" "$2" "$3" 

In the first case, if you passed the argument to the script itself

 [bash]$ ./test.sh -p"1 2 3" 

Then they will reach the parse_param function as parse_param –p 1 2 3, which, believe me, is not what you expected.

Argumenting arguments helps, but gives rise to another problem. Now this part will stop working

  :) echo "Option -$OPTARG requires an argument (getopts)" >&2 exit 1 ;; 

In place of this, $ OPTARG will be an empty string, which is quite valid from the point of view of getopts.

So make it simple and correct.

 parse_param "$@" 

Options with arguments and argument checking

To enable the initial protection against the absence of an argument, each such option must be terminated with “:” and add the appropriate handler.

  :) echo "Option -$OPTARG requires an argument (getopts)" >&2 exit 1 ;; 

Why is this pribluda?

 function check_arg(){ if [[ $2 == -* ]]; then echo "Option $1 requires an argument" >&2 exit 1 fi } 

Try to remove the call to this function here.

 check_arg "-p" "$OPTARG" 

And make this challenge

 [bash]$ ./test.sh -p -n 

And you get that “-n” will be an argument to the –p option. Is this what you expected? But not me.

Not valid arguments

In order for this piece of code to do what you want

  \?) echo "Invalid option: -$OPTARG" >&2 exit 1 ;; 

The getopts parameter list must begin with ":" (getopts " : np:")

I hope it turned out not too emotionally, and for some it will allow you to save time for more interesting activities.