getopt and case function not executing

Question

I encountered such a problem when passing a parameter to a script, the function corresponding to the case menu is not executed. The script accepts parameters as input and performs the appropriate actions

#!/bin/bash
usage () {
echo " Usage:
-h, --help         #Displaying help
-p, --proc         #Working with directory /proc
-c, --cpu          #Working with CPU
-m, --memory       #Working with memory
-d, --disks        #Working with disks
-n, --network      #Working with networks
-la, --loadaverage #Displaying the load average on the system
-k, --kill         #Sending signals to processes
-o, --output       #Saving the results of script to disk"
exit2
}
proc () {
if [ -n "$1" ]
then
      if [ -z "$2" ]
      then
             ls /proc
      else
           cat /proc/"$2"
       fi
fi
}
parsed_arguments=$(getopt -o hp:c:m:d:n:la:k:o: --long help,proc:,cpu:,memory:,disks:,network:,loadaverage:,kill:,output:)
if [[ "${#}" -eq "" ]]
then
       usage
fi
eval set -- "$parsed_arguments"
while :
do
      case "$1" in
      -h | --help) echo " Showing usage!"; usage
       ;;
       -p | --proc) proc
       ;;
     esac
done

f the script does not receive any parameters, then a description of the options should be displayed, but if the script receives the first parameter starting with "-" or "--" as input, then the functions corresponding to the letter or word following the "-" or "--" should be executed. Example

No parameters:
./script.sh
 Usage:
-h, --help         #Displaying help
-p, --proc         #Working with directory /proc
-c, --cpu          #Working with CPU
-m, --memory       #Working with memory
-d, --disks        #Working with disks
-n, --network      #Working with networks
-la, --loadaverage #Displaying the load average on the system
-k, --kill         #Sending signals to processes
-o, --output       #Saving the results of script to disk"
With one parameters:
./script.sh -p
or
./script.sh --proc
The contents of the /proc directory should be displayed
With additional parameters:
 ]]./script.sh -p cpuinfo
or
./script.sh --proc cpuinfo
The contents of the file passed through the additional parameter should be displayed

A script without arguments is executed, but not with arguments. Can you tell me what could be the reason for the fact that when passing arguments to the script, the corresponding functions are not executed.

You seem to have forgotten the arguments in the call to your proc function. — Kusalananda, Sep 30 '22 at 12:27
You're checking the number arguments before doing option processing — Stéphane Chazelas, Sep 30 '22 at 12:30
You have : after many of the options which according to usage are not meant to take arguments — Stéphane Chazelas, Sep 30 '22 at 12:31
You're trying to accept a short option with two letters (-la) — Stéphane Chazelas, Sep 30 '22 at 12:33
Your most immediate issue is not related to calling your proc function correctly. It's about using getopt correctly. Unfortunately I can't help you since I am not on a Linux system with the same non-standard getopt implementation that you seem to be trying to use. See Stéphanes' various comments. — Kusalananda, Sep 30 '22 at 16:03
It looks like GNU getopt, @Kusalananda. It rewrites the command line into a standardised form so that options and their parameters are easy to parse (-ab value would get rewritten as -a -b value, etc.) Aside from the "did it work" check being better written to test $? rather than $# that part's reasonably ok — Chris Davies, Sep 30 '22 at 16:48
AFAIK, the "enhanced" getopt is from util-linux originally (but at least Busybox implements the same features too). The last time I looked, I didn't find a GNU implementation of it. The traditional (broken) getopt appears to be just as nonstandard as the enhanced one, at least I don't see getopt listed in https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/idx/ig.html — ilkkachu, Sep 30 '22 at 17:25
@ilkkachu the version I've got from util-linux claims, "It can do anything that the GNU getopt(3) routines can do" and "copyright (c) 1997-2005 by Frodo Looijaard" but released under GNU GPL v2. I figured that was "GNU"-enough to be called GNU. Or does it need to be hosted at gnu.org for that moniker? — Chris Davies, Sep 30 '22 at 17:33
@roaima, well, a lot of stuff is released under the GNU GPL (v2 or v3), but they're still not GNU projects, as in governed their structure (i.e. under RMS's thumb). Consider rsync or heck, the Linux kernel. As far as I understand, that name "util-linux" refers to the kernel folks, too. That getopt(3) reference is to the C function, which yes, the GNU C library implements. Most of what it does is standard, but glibc also supports optional option-arguments, which aren't. (Then again, e.g. FreeBSD and OpenBSD also support that, so it's not just GNU) — ilkkachu, Oct 01 '22 at 08:49

score 1 · Answer 1 · answered Sep 30 '22 at 17:23

getopt requires the command-line arguments to parse as, well, arguments to itself. If you're using the util-linux/Busybox getopt that actually works, the proper syntax is to append -- and then the arguments to parse, usually like

getopt -o abc --long this,that -- "$@"

where "$@" expands to the arguments of the script itself.

Then you also have a never-ending while loop, as you never shift the arguments, but always look at the same $1.

You may have other issues in the script too, but fixing those should get you started. You can run the script with bash -x myscript, or add set -x to the start of the script to see the commands it actually runs.

See getopt, getopts or manual parsing - what to use when I want to support both short and long options? or this SO answer or my answer here for examples on how to use getopt.

getopt and case function not executing

1 Answers1