I am taking a course on Lynda and they show this code below. I didn't fully understand some parts. Please see the questions within the code.
Thank you for your input and time.
Regards,
function usage {
echo Options are -r -h -b -x --branch --version --help --exclude
exit 1
}
function handleopts {
OPTS=`getopt -o r:hb::x: -l exclude: -l branch:: -l help -l version -- "$@"`
#### Question 1: How does the "-- $@" work here ####
if [ $? != 0 ]
then
echo ERROR parsing arguments >&2
exit 1
fi
eval set -- "$OPTS"
#### Question 2: I understand that set -- $variable sets the content of $variable to the positional parameters, but how does it work here? What are the PP here? ####
while true ; do
case "$1" in
-r ) rightway=$2
shift 2;;
#### Question 3: I assume that shift 2 means shift shift, but why is it needed here? ####
--version ) echo "Version 1.2";
exit 0;;
-h | --help ) usage;
shift;;
-b | --branch)
case "$2" in
"") branchname="default" ; shift 2 ;;
*) branchname="$2" ; shift 2 ;;
esac ;;
--) shift; break;;
esac
done
if [ "$#" -ne 0 ]
then
echo Error extra command line arguments "$@"
usage
fi
}
rightway=no
handleopts $@
echo rightway = $rightway
echo branchname = $branchname
-- "$@" just means, "take the following arguments literally" and "all the following arguments, properly separated and quoted". If your arguments are "a b" "c d" "e f", "$@" will put them in as "a b" "c d" "e f", not "a" "b" "c" "d" "e" "f".
The 'shift' eats a commandline argument, i.e. converts $1=a, $2=b, $3=c, $4=d into $1=b, $2=c, $3=d. shift 2 moves it all the way to $1=c, $2=d. It's done since that particular branch uses an argument, so it has to remove two things from the list (the -r and the argument following it) not just one.
I have no idea why they're doing 'eval set', only theories. That's dangerous and dumb. They may be trying to process quotes inside quotes.
They are getting the values from 'getopt', the standard way to handle commandline arguments. I can't really explain its workings, but I'm sure others can.
Hi Corona688,
I agree wholeheartedly with your 1st three paragraphs.
But the "standard" way of handing command line arguments is getopts ; not getopt . In the early days of the Bourne shell, there was a getopt utility that had problems dealing with quoted option-arguments and was replaced by the getopts utility that is in the current standards. The getopts utility is processed in a loop extracting one option and its option-argument (if there is one for that option) each time through the loop. The version in the standard doesn't have any provision for processing long options (i.e., --optionname or --optionname=argument ), but many implementations of the getopts utility have extensions supporting them.
The standard getopts utility can handle command lines like:
producing identical results for any of the above. And, if operand1's 1st character is not a <hyphen>, will also recognize the following producing identical results to any of the above:
One might guess that the getopt utility called by the script in post #1 in this thread would normalize command line arguments splitting multiple option letters following a single <hyphen> into separate arguments each with its own <hyphen> and would split an an option with an option-argument presented as a single argument into two arguments so that the while loop in that script would work properly, but I have no idea whether the getopt actually being used by this application is this flexible.
I agree with the above and again: eval if used this way on external, user controlled parameters is especially dangerous. It should not be used this way!
Further observations:
the while true loop is faulty. There is no default case and the loop only ends when there is the option -- . If that is left out, no shifting takes place, so the script will enter an infinite loop. A while true loop is not the way one would normally do option handling with getopts anyway.
The unquoted function parameter $@ may alter the script's command line parameters when it passes it to the function. There should be double quotes around it..
The test for the number of non-option parameters is never reached [ "$#" -ne 0 ] when there are no options either..
We haven't been told what operating system or shell are being used for these tests, but if we use bash , ksh , sh , or zsh on macOS with the BSD based getopt utility available on that system (which says it was designed to behave the same as the Bell Labs getopt utility I described in post #3 in this thread), the command:
OPTS=`getopt -o r:hb::x: -l exclude: -l branch:: -l help -l version -- "$@"`
would set OPTS to:
-- r:hb::x: -l exclude: -l branch:: -l help -l version -- -r test
There are lots of things wrong with the script that has been posted for discussion in this thread many of which have already been mentioned at least once.
Instead of what this getopt utility is doing, to make the following while loop work correctly getopt with the shown arguments would have to return the string:
-r test --
instead of:
-- r:hb::x: -l exclude: -l branch:: -l help -l version -- -r test
Rather than trying to understand how this script works, you would be much better off taking the time to learn how to rewrite the script using getopts (perhaps using suggestions in the thread How to Use getopts with longoptions? from a couple of years ago as a starting point).