In a shell script, process options like -a -b but leave --abc alone?











up vote
0
down vote

favorite
1












So I have a shell script that does some preparation and then runs a utility.



The preparation can be affected by switches like -a or -n. The contents of the command line that are not such switches are to be passed to the utility. Currently my script has:



while getopts ":an" opt; do
case $opt in
a)
#something
;;
n)
#something else
;;
?)
echo "Invalid option: -$OPTARG" >&2
;;
esac
done
shift $((OPTIND-1))
#more prep
my_utility $@


However, this fails when I want to pass long-form options to the utility, such as --abc as that is interpreted as a, b, and c options by getopts.



So how can I process options in such a way that -a or -n is processed, but --abc remains untouched? Unless, of course, I dump Shell and do it in Python - then options would be very easy, but I also need to copy files and run utilities, and Python makes this awkward.










share|improve this question




















  • 1




    getopts is not able to process double dash arguments
    – Vlastimil
    11 hours ago










  • You could do this by copying the unrecognized options to a shell variable, and passing that to my_utility, but it requires keeping in mind special cases where the getopts parameter must handle options with values.
    – Thomas Dickey
    10 hours ago










  • I disagree with "I also need to copy files and run utilities, and Python makes this awkward." Use shutil.copy2() for the former and subprocess.check_call([...]) and subprocess.check_output([...]) for the latter. In many cases you can still keep these as one-liners. And the language expressiveness you gain for the rest of the script is definitely worth it!
    – Filipe Brandenburger
    9 hours ago















up vote
0
down vote

favorite
1












So I have a shell script that does some preparation and then runs a utility.



The preparation can be affected by switches like -a or -n. The contents of the command line that are not such switches are to be passed to the utility. Currently my script has:



while getopts ":an" opt; do
case $opt in
a)
#something
;;
n)
#something else
;;
?)
echo "Invalid option: -$OPTARG" >&2
;;
esac
done
shift $((OPTIND-1))
#more prep
my_utility $@


However, this fails when I want to pass long-form options to the utility, such as --abc as that is interpreted as a, b, and c options by getopts.



So how can I process options in such a way that -a or -n is processed, but --abc remains untouched? Unless, of course, I dump Shell and do it in Python - then options would be very easy, but I also need to copy files and run utilities, and Python makes this awkward.










share|improve this question




















  • 1




    getopts is not able to process double dash arguments
    – Vlastimil
    11 hours ago










  • You could do this by copying the unrecognized options to a shell variable, and passing that to my_utility, but it requires keeping in mind special cases where the getopts parameter must handle options with values.
    – Thomas Dickey
    10 hours ago










  • I disagree with "I also need to copy files and run utilities, and Python makes this awkward." Use shutil.copy2() for the former and subprocess.check_call([...]) and subprocess.check_output([...]) for the latter. In many cases you can still keep these as one-liners. And the language expressiveness you gain for the rest of the script is definitely worth it!
    – Filipe Brandenburger
    9 hours ago













up vote
0
down vote

favorite
1









up vote
0
down vote

favorite
1






1





So I have a shell script that does some preparation and then runs a utility.



The preparation can be affected by switches like -a or -n. The contents of the command line that are not such switches are to be passed to the utility. Currently my script has:



while getopts ":an" opt; do
case $opt in
a)
#something
;;
n)
#something else
;;
?)
echo "Invalid option: -$OPTARG" >&2
;;
esac
done
shift $((OPTIND-1))
#more prep
my_utility $@


However, this fails when I want to pass long-form options to the utility, such as --abc as that is interpreted as a, b, and c options by getopts.



So how can I process options in such a way that -a or -n is processed, but --abc remains untouched? Unless, of course, I dump Shell and do it in Python - then options would be very easy, but I also need to copy files and run utilities, and Python makes this awkward.










share|improve this question















So I have a shell script that does some preparation and then runs a utility.



The preparation can be affected by switches like -a or -n. The contents of the command line that are not such switches are to be passed to the utility. Currently my script has:



while getopts ":an" opt; do
case $opt in
a)
#something
;;
n)
#something else
;;
?)
echo "Invalid option: -$OPTARG" >&2
;;
esac
done
shift $((OPTIND-1))
#more prep
my_utility $@


However, this fails when I want to pass long-form options to the utility, such as --abc as that is interpreted as a, b, and c options by getopts.



So how can I process options in such a way that -a or -n is processed, but --abc remains untouched? Unless, of course, I dump Shell and do it in Python - then options would be very easy, but I also need to copy files and run utilities, and Python makes this awkward.







shell getopts






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited 10 hours ago









Filipe Brandenburger

5,7991624




5,7991624










asked 11 hours ago









Mikhail Ramendik

18810




18810








  • 1




    getopts is not able to process double dash arguments
    – Vlastimil
    11 hours ago










  • You could do this by copying the unrecognized options to a shell variable, and passing that to my_utility, but it requires keeping in mind special cases where the getopts parameter must handle options with values.
    – Thomas Dickey
    10 hours ago










  • I disagree with "I also need to copy files and run utilities, and Python makes this awkward." Use shutil.copy2() for the former and subprocess.check_call([...]) and subprocess.check_output([...]) for the latter. In many cases you can still keep these as one-liners. And the language expressiveness you gain for the rest of the script is definitely worth it!
    – Filipe Brandenburger
    9 hours ago














  • 1




    getopts is not able to process double dash arguments
    – Vlastimil
    11 hours ago










  • You could do this by copying the unrecognized options to a shell variable, and passing that to my_utility, but it requires keeping in mind special cases where the getopts parameter must handle options with values.
    – Thomas Dickey
    10 hours ago










  • I disagree with "I also need to copy files and run utilities, and Python makes this awkward." Use shutil.copy2() for the former and subprocess.check_call([...]) and subprocess.check_output([...]) for the latter. In many cases you can still keep these as one-liners. And the language expressiveness you gain for the rest of the script is definitely worth it!
    – Filipe Brandenburger
    9 hours ago








1




1




getopts is not able to process double dash arguments
– Vlastimil
11 hours ago




getopts is not able to process double dash arguments
– Vlastimil
11 hours ago












You could do this by copying the unrecognized options to a shell variable, and passing that to my_utility, but it requires keeping in mind special cases where the getopts parameter must handle options with values.
– Thomas Dickey
10 hours ago




You could do this by copying the unrecognized options to a shell variable, and passing that to my_utility, but it requires keeping in mind special cases where the getopts parameter must handle options with values.
– Thomas Dickey
10 hours ago












I disagree with "I also need to copy files and run utilities, and Python makes this awkward." Use shutil.copy2() for the former and subprocess.check_call([...]) and subprocess.check_output([...]) for the latter. In many cases you can still keep these as one-liners. And the language expressiveness you gain for the rest of the script is definitely worth it!
– Filipe Brandenburger
9 hours ago




I disagree with "I also need to copy files and run utilities, and Python makes this awkward." Use shutil.copy2() for the former and subprocess.check_call([...]) and subprocess.check_output([...]) for the latter. In many cases you can still keep these as one-liners. And the language expressiveness you gain for the rest of the script is definitely worth it!
– Filipe Brandenburger
9 hours ago










2 Answers
2






active

oldest

votes

















up vote
2
down vote













I don't see why you couldn't simulate long options by treating - as a short option requiring an argument:



$ cat /tmp/foo
while getopts :aq:-: opt; do
case $opt in
a) echo option -a;;
q) echo option -q with value "$OPTARG";;
-) case $OPTARG in
abc) echo option --abc;;
def=*) echo option --def with value "${OPTARG#*=}";;
*) echo >&2 "unknown option --$OPTARG";;
esac;;
:) echo >&2 "-$OPTARG needs an argument";;
*) echo >&2 "unknown option -$OPTARG";;
esac
done
shift "$((OPTIND - 1))"
echo argv: "$@"

$ sh /tmp/foo -a -qt --abc --def=ghi -- foo bar
option -a
option -q with value t
option --abc
option --def with value ghi
argv: foo bar


Of course, instead of echo'ing you could append them to a command line:



cmd=whatever
while getopts ...; do
...
abc) cmd="$cmd --abc";;
...
done
shift "$((OPTIND - 1))"
eval "$cmd "$@""





share|improve this answer



















  • 1




    Note that the second option won't be very robust at handling options with values (e.g. --long-opt='some value'). As usual, eval is a huge source of trouble...
    – Gordon Davisson
    4 hours ago










  • That's what I was warning about when stating There is a way to use the bash builtin getopts to mimic long options, but you should not do that as it's a kludge and not worth your effort as getopts cannot enforce the long specification. It's still elegant code, so not downvoting.
    – Fabby
    2 hours ago












  • Please explain how this "does not enforce the long specification". As to the eval + long opts with spaces in them in the 2nd ex, that could be easily worked around by a) using arrays b) using IFS and set -f c) using another portable trick that I'll edit in when I get something else than a phone to type on
    – mosvy
    1 hour ago




















up vote
1
down vote













To interpret double dash commands you need GNU's getopt instead of the built-in getopts.



There is a way to use the bash builtin getopts to mimic long options, but you should not do that as it's a kludge and not worth your effort as getopts cannot enforce the long specification.



So your script becomes:



#!/bin/bash

# Get options
OPTS=`getopt --options an: --long a_something,n_something_else: -n 'parse-options' -- "$@"`

if [ $? != 0 ] ; then echo "Failed parsing options." >&2 ; exit 1 ; fi

#echo parsed and cleaned up options
echo "$OPTS"
eval set -- "$OPTS"

bSomething=false
bSomethingElse=false

# "Endless" loop over the parsed options
while true; do
case "$1" in
-a | --a_something ) bSomething=true; shift ;;
-n | --n_something_else ) bSomethingElse=true; shift ;;
-- ) shift; break ;;
* ) break ;;
esac
done


For more information: man getopt

For even more information: man getopt(3)






share|improve this answer























  • Thank you! But I dont understand how this works. The while loop just goes through $1 until $1 becomes unrecognizeable, I like this. But what does getopts do, as that loop does not invoke it?
    – Mikhail Ramendik
    9 hours ago






  • 1




    @MikhailRamendik getopts parses the options, then prints them in a cleaned-up, standardized format. The set command then replaces the passed arguments with the cleaned-up version, so that the while loop can parse them easily.
    – Gordon Davisson
    4 hours ago










  • @GordonDavisson Thanks for responding while I was asleep. ;-) Code edited to clarify as well.
    – Fabby
    3 hours ago











Your Answer








StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














 

draft saved


draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f482060%2fin-a-shell-script-process-options-like-a-b-but-leave-abc-alone%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























2 Answers
2






active

oldest

votes








2 Answers
2






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
2
down vote













I don't see why you couldn't simulate long options by treating - as a short option requiring an argument:



$ cat /tmp/foo
while getopts :aq:-: opt; do
case $opt in
a) echo option -a;;
q) echo option -q with value "$OPTARG";;
-) case $OPTARG in
abc) echo option --abc;;
def=*) echo option --def with value "${OPTARG#*=}";;
*) echo >&2 "unknown option --$OPTARG";;
esac;;
:) echo >&2 "-$OPTARG needs an argument";;
*) echo >&2 "unknown option -$OPTARG";;
esac
done
shift "$((OPTIND - 1))"
echo argv: "$@"

$ sh /tmp/foo -a -qt --abc --def=ghi -- foo bar
option -a
option -q with value t
option --abc
option --def with value ghi
argv: foo bar


Of course, instead of echo'ing you could append them to a command line:



cmd=whatever
while getopts ...; do
...
abc) cmd="$cmd --abc";;
...
done
shift "$((OPTIND - 1))"
eval "$cmd "$@""





share|improve this answer



















  • 1




    Note that the second option won't be very robust at handling options with values (e.g. --long-opt='some value'). As usual, eval is a huge source of trouble...
    – Gordon Davisson
    4 hours ago










  • That's what I was warning about when stating There is a way to use the bash builtin getopts to mimic long options, but you should not do that as it's a kludge and not worth your effort as getopts cannot enforce the long specification. It's still elegant code, so not downvoting.
    – Fabby
    2 hours ago












  • Please explain how this "does not enforce the long specification". As to the eval + long opts with spaces in them in the 2nd ex, that could be easily worked around by a) using arrays b) using IFS and set -f c) using another portable trick that I'll edit in when I get something else than a phone to type on
    – mosvy
    1 hour ago

















up vote
2
down vote













I don't see why you couldn't simulate long options by treating - as a short option requiring an argument:



$ cat /tmp/foo
while getopts :aq:-: opt; do
case $opt in
a) echo option -a;;
q) echo option -q with value "$OPTARG";;
-) case $OPTARG in
abc) echo option --abc;;
def=*) echo option --def with value "${OPTARG#*=}";;
*) echo >&2 "unknown option --$OPTARG";;
esac;;
:) echo >&2 "-$OPTARG needs an argument";;
*) echo >&2 "unknown option -$OPTARG";;
esac
done
shift "$((OPTIND - 1))"
echo argv: "$@"

$ sh /tmp/foo -a -qt --abc --def=ghi -- foo bar
option -a
option -q with value t
option --abc
option --def with value ghi
argv: foo bar


Of course, instead of echo'ing you could append them to a command line:



cmd=whatever
while getopts ...; do
...
abc) cmd="$cmd --abc";;
...
done
shift "$((OPTIND - 1))"
eval "$cmd "$@""





share|improve this answer



















  • 1




    Note that the second option won't be very robust at handling options with values (e.g. --long-opt='some value'). As usual, eval is a huge source of trouble...
    – Gordon Davisson
    4 hours ago










  • That's what I was warning about when stating There is a way to use the bash builtin getopts to mimic long options, but you should not do that as it's a kludge and not worth your effort as getopts cannot enforce the long specification. It's still elegant code, so not downvoting.
    – Fabby
    2 hours ago












  • Please explain how this "does not enforce the long specification". As to the eval + long opts with spaces in them in the 2nd ex, that could be easily worked around by a) using arrays b) using IFS and set -f c) using another portable trick that I'll edit in when I get something else than a phone to type on
    – mosvy
    1 hour ago















up vote
2
down vote










up vote
2
down vote









I don't see why you couldn't simulate long options by treating - as a short option requiring an argument:



$ cat /tmp/foo
while getopts :aq:-: opt; do
case $opt in
a) echo option -a;;
q) echo option -q with value "$OPTARG";;
-) case $OPTARG in
abc) echo option --abc;;
def=*) echo option --def with value "${OPTARG#*=}";;
*) echo >&2 "unknown option --$OPTARG";;
esac;;
:) echo >&2 "-$OPTARG needs an argument";;
*) echo >&2 "unknown option -$OPTARG";;
esac
done
shift "$((OPTIND - 1))"
echo argv: "$@"

$ sh /tmp/foo -a -qt --abc --def=ghi -- foo bar
option -a
option -q with value t
option --abc
option --def with value ghi
argv: foo bar


Of course, instead of echo'ing you could append them to a command line:



cmd=whatever
while getopts ...; do
...
abc) cmd="$cmd --abc";;
...
done
shift "$((OPTIND - 1))"
eval "$cmd "$@""





share|improve this answer














I don't see why you couldn't simulate long options by treating - as a short option requiring an argument:



$ cat /tmp/foo
while getopts :aq:-: opt; do
case $opt in
a) echo option -a;;
q) echo option -q with value "$OPTARG";;
-) case $OPTARG in
abc) echo option --abc;;
def=*) echo option --def with value "${OPTARG#*=}";;
*) echo >&2 "unknown option --$OPTARG";;
esac;;
:) echo >&2 "-$OPTARG needs an argument";;
*) echo >&2 "unknown option -$OPTARG";;
esac
done
shift "$((OPTIND - 1))"
echo argv: "$@"

$ sh /tmp/foo -a -qt --abc --def=ghi -- foo bar
option -a
option -q with value t
option --abc
option --def with value ghi
argv: foo bar


Of course, instead of echo'ing you could append them to a command line:



cmd=whatever
while getopts ...; do
...
abc) cmd="$cmd --abc";;
...
done
shift "$((OPTIND - 1))"
eval "$cmd "$@""






share|improve this answer














share|improve this answer



share|improve this answer








edited 8 hours ago

























answered 9 hours ago









mosvy

4,140221




4,140221








  • 1




    Note that the second option won't be very robust at handling options with values (e.g. --long-opt='some value'). As usual, eval is a huge source of trouble...
    – Gordon Davisson
    4 hours ago










  • That's what I was warning about when stating There is a way to use the bash builtin getopts to mimic long options, but you should not do that as it's a kludge and not worth your effort as getopts cannot enforce the long specification. It's still elegant code, so not downvoting.
    – Fabby
    2 hours ago












  • Please explain how this "does not enforce the long specification". As to the eval + long opts with spaces in them in the 2nd ex, that could be easily worked around by a) using arrays b) using IFS and set -f c) using another portable trick that I'll edit in when I get something else than a phone to type on
    – mosvy
    1 hour ago
















  • 1




    Note that the second option won't be very robust at handling options with values (e.g. --long-opt='some value'). As usual, eval is a huge source of trouble...
    – Gordon Davisson
    4 hours ago










  • That's what I was warning about when stating There is a way to use the bash builtin getopts to mimic long options, but you should not do that as it's a kludge and not worth your effort as getopts cannot enforce the long specification. It's still elegant code, so not downvoting.
    – Fabby
    2 hours ago












  • Please explain how this "does not enforce the long specification". As to the eval + long opts with spaces in them in the 2nd ex, that could be easily worked around by a) using arrays b) using IFS and set -f c) using another portable trick that I'll edit in when I get something else than a phone to type on
    – mosvy
    1 hour ago










1




1




Note that the second option won't be very robust at handling options with values (e.g. --long-opt='some value'). As usual, eval is a huge source of trouble...
– Gordon Davisson
4 hours ago




Note that the second option won't be very robust at handling options with values (e.g. --long-opt='some value'). As usual, eval is a huge source of trouble...
– Gordon Davisson
4 hours ago












That's what I was warning about when stating There is a way to use the bash builtin getopts to mimic long options, but you should not do that as it's a kludge and not worth your effort as getopts cannot enforce the long specification. It's still elegant code, so not downvoting.
– Fabby
2 hours ago






That's what I was warning about when stating There is a way to use the bash builtin getopts to mimic long options, but you should not do that as it's a kludge and not worth your effort as getopts cannot enforce the long specification. It's still elegant code, so not downvoting.
– Fabby
2 hours ago














Please explain how this "does not enforce the long specification". As to the eval + long opts with spaces in them in the 2nd ex, that could be easily worked around by a) using arrays b) using IFS and set -f c) using another portable trick that I'll edit in when I get something else than a phone to type on
– mosvy
1 hour ago






Please explain how this "does not enforce the long specification". As to the eval + long opts with spaces in them in the 2nd ex, that could be easily worked around by a) using arrays b) using IFS and set -f c) using another portable trick that I'll edit in when I get something else than a phone to type on
– mosvy
1 hour ago














up vote
1
down vote













To interpret double dash commands you need GNU's getopt instead of the built-in getopts.



There is a way to use the bash builtin getopts to mimic long options, but you should not do that as it's a kludge and not worth your effort as getopts cannot enforce the long specification.



So your script becomes:



#!/bin/bash

# Get options
OPTS=`getopt --options an: --long a_something,n_something_else: -n 'parse-options' -- "$@"`

if [ $? != 0 ] ; then echo "Failed parsing options." >&2 ; exit 1 ; fi

#echo parsed and cleaned up options
echo "$OPTS"
eval set -- "$OPTS"

bSomething=false
bSomethingElse=false

# "Endless" loop over the parsed options
while true; do
case "$1" in
-a | --a_something ) bSomething=true; shift ;;
-n | --n_something_else ) bSomethingElse=true; shift ;;
-- ) shift; break ;;
* ) break ;;
esac
done


For more information: man getopt

For even more information: man getopt(3)






share|improve this answer























  • Thank you! But I dont understand how this works. The while loop just goes through $1 until $1 becomes unrecognizeable, I like this. But what does getopts do, as that loop does not invoke it?
    – Mikhail Ramendik
    9 hours ago






  • 1




    @MikhailRamendik getopts parses the options, then prints them in a cleaned-up, standardized format. The set command then replaces the passed arguments with the cleaned-up version, so that the while loop can parse them easily.
    – Gordon Davisson
    4 hours ago










  • @GordonDavisson Thanks for responding while I was asleep. ;-) Code edited to clarify as well.
    – Fabby
    3 hours ago















up vote
1
down vote













To interpret double dash commands you need GNU's getopt instead of the built-in getopts.



There is a way to use the bash builtin getopts to mimic long options, but you should not do that as it's a kludge and not worth your effort as getopts cannot enforce the long specification.



So your script becomes:



#!/bin/bash

# Get options
OPTS=`getopt --options an: --long a_something,n_something_else: -n 'parse-options' -- "$@"`

if [ $? != 0 ] ; then echo "Failed parsing options." >&2 ; exit 1 ; fi

#echo parsed and cleaned up options
echo "$OPTS"
eval set -- "$OPTS"

bSomething=false
bSomethingElse=false

# "Endless" loop over the parsed options
while true; do
case "$1" in
-a | --a_something ) bSomething=true; shift ;;
-n | --n_something_else ) bSomethingElse=true; shift ;;
-- ) shift; break ;;
* ) break ;;
esac
done


For more information: man getopt

For even more information: man getopt(3)






share|improve this answer























  • Thank you! But I dont understand how this works. The while loop just goes through $1 until $1 becomes unrecognizeable, I like this. But what does getopts do, as that loop does not invoke it?
    – Mikhail Ramendik
    9 hours ago






  • 1




    @MikhailRamendik getopts parses the options, then prints them in a cleaned-up, standardized format. The set command then replaces the passed arguments with the cleaned-up version, so that the while loop can parse them easily.
    – Gordon Davisson
    4 hours ago










  • @GordonDavisson Thanks for responding while I was asleep. ;-) Code edited to clarify as well.
    – Fabby
    3 hours ago













up vote
1
down vote










up vote
1
down vote









To interpret double dash commands you need GNU's getopt instead of the built-in getopts.



There is a way to use the bash builtin getopts to mimic long options, but you should not do that as it's a kludge and not worth your effort as getopts cannot enforce the long specification.



So your script becomes:



#!/bin/bash

# Get options
OPTS=`getopt --options an: --long a_something,n_something_else: -n 'parse-options' -- "$@"`

if [ $? != 0 ] ; then echo "Failed parsing options." >&2 ; exit 1 ; fi

#echo parsed and cleaned up options
echo "$OPTS"
eval set -- "$OPTS"

bSomething=false
bSomethingElse=false

# "Endless" loop over the parsed options
while true; do
case "$1" in
-a | --a_something ) bSomething=true; shift ;;
-n | --n_something_else ) bSomethingElse=true; shift ;;
-- ) shift; break ;;
* ) break ;;
esac
done


For more information: man getopt

For even more information: man getopt(3)






share|improve this answer














To interpret double dash commands you need GNU's getopt instead of the built-in getopts.



There is a way to use the bash builtin getopts to mimic long options, but you should not do that as it's a kludge and not worth your effort as getopts cannot enforce the long specification.



So your script becomes:



#!/bin/bash

# Get options
OPTS=`getopt --options an: --long a_something,n_something_else: -n 'parse-options' -- "$@"`

if [ $? != 0 ] ; then echo "Failed parsing options." >&2 ; exit 1 ; fi

#echo parsed and cleaned up options
echo "$OPTS"
eval set -- "$OPTS"

bSomething=false
bSomethingElse=false

# "Endless" loop over the parsed options
while true; do
case "$1" in
-a | --a_something ) bSomething=true; shift ;;
-n | --n_something_else ) bSomethingElse=true; shift ;;
-- ) shift; break ;;
* ) break ;;
esac
done


For more information: man getopt

For even more information: man getopt(3)







share|improve this answer














share|improve this answer



share|improve this answer








edited 3 hours ago

























answered 10 hours ago









Fabby

2,84011124




2,84011124












  • Thank you! But I dont understand how this works. The while loop just goes through $1 until $1 becomes unrecognizeable, I like this. But what does getopts do, as that loop does not invoke it?
    – Mikhail Ramendik
    9 hours ago






  • 1




    @MikhailRamendik getopts parses the options, then prints them in a cleaned-up, standardized format. The set command then replaces the passed arguments with the cleaned-up version, so that the while loop can parse them easily.
    – Gordon Davisson
    4 hours ago










  • @GordonDavisson Thanks for responding while I was asleep. ;-) Code edited to clarify as well.
    – Fabby
    3 hours ago


















  • Thank you! But I dont understand how this works. The while loop just goes through $1 until $1 becomes unrecognizeable, I like this. But what does getopts do, as that loop does not invoke it?
    – Mikhail Ramendik
    9 hours ago






  • 1




    @MikhailRamendik getopts parses the options, then prints them in a cleaned-up, standardized format. The set command then replaces the passed arguments with the cleaned-up version, so that the while loop can parse them easily.
    – Gordon Davisson
    4 hours ago










  • @GordonDavisson Thanks for responding while I was asleep. ;-) Code edited to clarify as well.
    – Fabby
    3 hours ago
















Thank you! But I dont understand how this works. The while loop just goes through $1 until $1 becomes unrecognizeable, I like this. But what does getopts do, as that loop does not invoke it?
– Mikhail Ramendik
9 hours ago




Thank you! But I dont understand how this works. The while loop just goes through $1 until $1 becomes unrecognizeable, I like this. But what does getopts do, as that loop does not invoke it?
– Mikhail Ramendik
9 hours ago




1




1




@MikhailRamendik getopts parses the options, then prints them in a cleaned-up, standardized format. The set command then replaces the passed arguments with the cleaned-up version, so that the while loop can parse them easily.
– Gordon Davisson
4 hours ago




@MikhailRamendik getopts parses the options, then prints them in a cleaned-up, standardized format. The set command then replaces the passed arguments with the cleaned-up version, so that the while loop can parse them easily.
– Gordon Davisson
4 hours ago












@GordonDavisson Thanks for responding while I was asleep. ;-) Code edited to clarify as well.
– Fabby
3 hours ago




@GordonDavisson Thanks for responding while I was asleep. ;-) Code edited to clarify as well.
– Fabby
3 hours ago


















 

draft saved


draft discarded



















































 


draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f482060%2fin-a-shell-script-process-options-like-a-b-but-leave-abc-alone%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Accessing regular linux commands in Huawei's Dopra Linux

Can't connect RFCOMM socket: Host is down

Kernel panic - not syncing: Fatal Exception in Interrupt