option followed by : taking next option if argument missing with getopts

Hi all,

I am parsing command line options using getopts.

The problem is that mandatory argument options following ":" is taking next option as argument if it is not followed by any argument.
Below is the script:

while getopts :hd:t:s:l:p:f: opt
do
case "$opt" in
-h|-\?) usage;;
-d) DEBUG=true;export SCRIPT_LOG_LEVEL=DEBUG ;;
-t) DEVTYPE="$OPTARG" ;;

    -s\)  SIG_IP="$OPTARG"; export SOCKS5_SERVER="$OPTARG:9001" ;;
    -l\)  HOST_LOGIN="$OPTARG";;
                         
    -p\)  PASSWORD="$OPTARG" ;;
        
    -f\)  cl\_cfile_specd=1
         export RUNNING\_CONFIG_FILE="$OPTARG" ;;
            
    *\)  logmsg "Unrecognized param usage";;         
esac

done
if I run the script as:
$./script.sh -d -t rdsk -s 12.3.4.5 -l guru -p -f /usr/local/sc.conf
the option -p is taking -f as argument.

Please help me how to throw an error and exit the script if mandatory argument is not passed to the script.

Also how to deal with options having -- ie --logfile.

Please help with the above problem

Hi.

How should getopts know that the string "-f" is not an appropriate value for the argument of option "-p"? ... cheers, drl

PS In the getopts I use, the case selectors should not have leading "-" characters.

PPS Also note that you have set "d:", but did not use OPTARG in the case selector for "-d".

As a remark on design, perhaps they should not be "options" if they are mandatory.

After the while loop, check if password or config file is unset, and die if it is?

I don't think there's a standard way to get long options with getopts; you can roll your own, though.

while :
do
  case $# in 0) break;; esac
  case $1 in 
    -h|-\?|--help) usage;;
    -d|--debug) DEBUG=true;export SCRIPT_LOG_LEVEL=DEBUG; shift ;;
    -t|--type) DEVTYPE="$2"; shift; shift ;;
    -s|--socks) SIG_IP="$2"; export SOCKS5_SERVER="$2:9001"; shift; shift ;;
    -l|--login) HOST_LOGIN="$2"; shift; shift;;
    -p|--password) PASSWORD="$2"; shift; shift ;;
    -f|--config-file) cl_cfile_specd=1
        export RUNNING_CONFIG_FILE="$2"; shift; shift ;;
    -*) logmsg "Unrecognized param usage";;
  esac
done

Making it die gracefully when an option which requires an argument doesn't receive any (i.e. $2 is not set at all) is left as an exercise. The problem of seeing that $2 is the next option is artificial intelligence (or you could invent a separate mechanism for specifying an argument which begins with dash, so that you can forbid option arguments to start with a dash in the general case. I don't know if that's good or bad usability).