getopts does not seem to work
I am trying to run the following script using getopts to parse the options but it does not seem to work:
#!/bin/bash
set -x
echo $@
while getopts "rf" opt
do
case "${opt}" in
r)
ropt=${OPTARG}
;;
f)
fopt=${OPTARG}
;;
esac
done
shift $((OPTIND -1))
echo $fopt $ropt
The output I get is:
$ ./myscript.sh -f opt2 -r opt1
+ echo -f opt2 -r opt1
-f opt2 -r opt1
+ getopts rf opt
+ case "${opt}" in
+ fopt=
+ getopts rf opt
+ shift 1
+ echo
+ set +x
Do you have any ideas on what am I doing wrong?
bash getopts
edited Dec 12 at 11:24
Kusalananda
121k16229372
asked Dec 12 at 10:36
trikelef
15718
add a comment |
I am trying to run the following script using getopts to parse the options but it does not seem to work:
#!/bin/bash
set -x
echo $@
while getopts "rf" opt
do
case "${opt}" in
r)
ropt=${OPTARG}
;;
f)
fopt=${OPTARG}
;;
esac
done
shift $((OPTIND -1))
echo $fopt $ropt
The output I get is:
$ ./myscript.sh -f opt2 -r opt1
+ echo -f opt2 -r opt1
-f opt2 -r opt1
+ getopts rf opt
+ case "${opt}" in
+ fopt=
+ getopts rf opt
+ shift 1
+ echo
+ set +x
Do you have any ideas on what am I doing wrong?
bash getopts
edited Dec 12 at 11:24
Kusalananda
121k16229372
asked Dec 12 at 10:36
trikelef
15718
add a comment |
I am trying to run the following script using getopts to parse the options but it does not seem to work:
#!/bin/bash
set -x
echo $@
while getopts "rf" opt
do
case "${opt}" in
r)
ropt=${OPTARG}
;;
f)
fopt=${OPTARG}
;;
esac
done
shift $((OPTIND -1))
echo $fopt $ropt
The output I get is:
$ ./myscript.sh -f opt2 -r opt1
+ echo -f opt2 -r opt1
-f opt2 -r opt1
+ getopts rf opt
+ case "${opt}" in
+ fopt=
+ getopts rf opt
+ shift 1
+ echo
+ set +x
Do you have any ideas on what am I doing wrong?
bash getopts
edited Dec 12 at 11:24
Kusalananda
121k16229372
asked Dec 12 at 10:36
trikelef
15718
I am trying to run the following script using getopts to parse the options but it does not seem to work:
#!/bin/bash
set -x
echo $@
while getopts "rf" opt
do
case "${opt}" in
r)
ropt=${OPTARG}
;;
f)
fopt=${OPTARG}
;;
esac
done
shift $((OPTIND -1))
echo $fopt $ropt
The output I get is:
$ ./myscript.sh -f opt2 -r opt1
+ echo -f opt2 -r opt1
-f opt2 -r opt1
+ getopts rf opt
+ case "${opt}" in
+ fopt=
+ getopts rf opt
+ shift 1
+ echo
+ set +x
Do you have any ideas on what am I doing wrong?
bash getopts
bash getopts
edited Dec 12 at 11:24
Kusalananda
121k16229372
asked Dec 12 at 10:36
trikelef
15718
edited Dec 12 at 11:24
Kusalananda
121k16229372
asked Dec 12 at 10:36
trikelef
15718
edited Dec 12 at 11:24
Kusalananda
121k16229372
edited Dec 12 at 11:24
Kusalananda
121k16229372
edited Dec 12 at 11:24
Kusalananda
121k16229372
121k16229372
asked Dec 12 at 10:36
trikelef
15718
asked Dec 12 at 10:36
trikelef
15718
asked Dec 12 at 10:36
trikelef
15718
15718
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
You expect your options to take option-arguments, but you don't let getopts know about this.
You should use
while getopts "r:f:" opt; do ...; done
i.e., each option that takes an argument should have : after it in the argument string to getopts.
You'll probably also want a default case branch at the end to handle invalid options:
*) usage >&2
exit 1
(the error message (about invalid option or missing option argument) will be displayed by getopts itself, usage is expected to be a function that you will have defined that prints a short help message to standard output).
Also, don't forget to double quote all expansions, even $(( OPTIND - 1 )).
Related to that last point:
- When is double-quoting necessary?
answered Dec 12 at 10:40
Kusalananda
121k16229372
Why double quote$((OPTIND -1))? Isn't the result of an arithmetic expression always a number?
– user000001
Dec 12 at 17:43
2
@user000001 Yes, and$IFSmay include digits. which means that the number could be split into multiple words/numbers. Test withn=123; ( IFS=13; echo $n ).
– Kusalananda
Dec 12 at 17:45
Thant's interesting, never thought of that case
– user000001
Dec 12 at 17:47
@user000001 Very few does. Fortunately, most shells resetIFSfor each new shell invocation.dashdoes not, so potentially one couldexport IFS=0123456789before running a/bin/shshell script on Unices whereshisdashjust to see in what way it breaks.
– Kusalananda
Dec 12 at 17:48
I more benign example might be someone settingIFS=-to split something on dashes, and then not resetting it, causing the leading minus sign to be lost. Arguably the bug would be caused by not resetting the original value ofIFSand not by the lack of quotes, but I guess it never hurts to program defensively.
– user000001
Dec 12 at 18:02
add a comment |
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',
autoActivateHeartbeat: false,
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f487548%2fgetopts-does-not-seem-to-work%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
You expect your options to take option-arguments, but you don't let getopts know about this.
You should use
while getopts "r:f:" opt; do ...; done
i.e., each option that takes an argument should have : after it in the argument string to getopts.
You'll probably also want a default case branch at the end to handle invalid options:
*) usage >&2
exit 1
(the error message (about invalid option or missing option argument) will be displayed by getopts itself, usage is expected to be a function that you will have defined that prints a short help message to standard output).
Also, don't forget to double quote all expansions, even $(( OPTIND - 1 )).
Related to that last point:
- When is double-quoting necessary?
answered Dec 12 at 10:40
Kusalananda
121k16229372
Why double quote$((OPTIND -1))? Isn't the result of an arithmetic expression always a number?
– user000001
Dec 12 at 17:43
2
@user000001 Yes, and$IFSmay include digits. which means that the number could be split into multiple words/numbers. Test withn=123; ( IFS=13; echo $n ).
– Kusalananda
Dec 12 at 17:45
Thant's interesting, never thought of that case
– user000001
Dec 12 at 17:47
@user000001 Very few does. Fortunately, most shells resetIFSfor each new shell invocation.dashdoes not, so potentially one couldexport IFS=0123456789before running a/bin/shshell script on Unices whereshisdashjust to see in what way it breaks.
– Kusalananda
Dec 12 at 17:48
I more benign example might be someone settingIFS=-to split something on dashes, and then not resetting it, causing the leading minus sign to be lost. Arguably the bug would be caused by not resetting the original value ofIFSand not by the lack of quotes, but I guess it never hurts to program defensively.
– user000001
Dec 12 at 18:02
add a comment |
You expect your options to take option-arguments, but you don't let getopts know about this.
You should use
while getopts "r:f:" opt; do ...; done
i.e., each option that takes an argument should have : after it in the argument string to getopts.
You'll probably also want a default case branch at the end to handle invalid options:
*) usage >&2
exit 1
(the error message (about invalid option or missing option argument) will be displayed by getopts itself, usage is expected to be a function that you will have defined that prints a short help message to standard output).
Also, don't forget to double quote all expansions, even $(( OPTIND - 1 )).
Related to that last point:
- When is double-quoting necessary?
answered Dec 12 at 10:40
Kusalananda
121k16229372
Why double quote$((OPTIND -1))? Isn't the result of an arithmetic expression always a number?
– user000001
Dec 12 at 17:43
2
@user000001 Yes, and$IFSmay include digits. which means that the number could be split into multiple words/numbers. Test withn=123; ( IFS=13; echo $n ).
– Kusalananda
Dec 12 at 17:45
Thant's interesting, never thought of that case
– user000001
Dec 12 at 17:47
@user000001 Very few does. Fortunately, most shells resetIFSfor each new shell invocation.dashdoes not, so potentially one couldexport IFS=0123456789before running a/bin/shshell script on Unices whereshisdashjust to see in what way it breaks.
– Kusalananda
Dec 12 at 17:48
I more benign example might be someone settingIFS=-to split something on dashes, and then not resetting it, causing the leading minus sign to be lost. Arguably the bug would be caused by not resetting the original value ofIFSand not by the lack of quotes, but I guess it never hurts to program defensively.
– user000001
Dec 12 at 18:02
add a comment |
You expect your options to take option-arguments, but you don't let getopts know about this.
You should use
while getopts "r:f:" opt; do ...; done
i.e., each option that takes an argument should have : after it in the argument string to getopts.
You'll probably also want a default case branch at the end to handle invalid options:
*) usage >&2
exit 1
(the error message (about invalid option or missing option argument) will be displayed by getopts itself, usage is expected to be a function that you will have defined that prints a short help message to standard output).
Also, don't forget to double quote all expansions, even $(( OPTIND - 1 )).
Related to that last point:
- When is double-quoting necessary?
answered Dec 12 at 10:40
Kusalananda
121k16229372
You expect your options to take option-arguments, but you don't let getopts know about this.
You should use
while getopts "r:f:" opt; do ...; done
i.e., each option that takes an argument should have : after it in the argument string to getopts.
You'll probably also want a default case branch at the end to handle invalid options:
*) usage >&2
exit 1
(the error message (about invalid option or missing option argument) will be displayed by getopts itself, usage is expected to be a function that you will have defined that prints a short help message to standard output).
Also, don't forget to double quote all expansions, even $(( OPTIND - 1 )).
Related to that last point:
- When is double-quoting necessary?
answered Dec 12 at 10:40
Kusalananda
121k16229372
edited Dec 12 at 11:37
answered Dec 12 at 10:40
Kusalananda
121k16229372
answered Dec 12 at 10:40
Kusalananda
121k16229372
answered Dec 12 at 10:40
Kusalananda
121k16229372
121k16229372
Why double quote$((OPTIND -1))? Isn't the result of an arithmetic expression always a number?
– user000001
Dec 12 at 17:43
2
@user000001 Yes, and$IFSmay include digits. which means that the number could be split into multiple words/numbers. Test withn=123; ( IFS=13; echo $n ).
– Kusalananda
Dec 12 at 17:45
Thant's interesting, never thought of that case
– user000001
Dec 12 at 17:47
@user000001 Very few does. Fortunately, most shells resetIFSfor each new shell invocation.dashdoes not, so potentially one couldexport IFS=0123456789before running a/bin/shshell script on Unices whereshisdashjust to see in what way it breaks.
– Kusalananda
Dec 12 at 17:48
I more benign example might be someone settingIFS=-to split something on dashes, and then not resetting it, causing the leading minus sign to be lost. Arguably the bug would be caused by not resetting the original value ofIFSand not by the lack of quotes, but I guess it never hurts to program defensively.
– user000001
Dec 12 at 18:02
add a comment |
Why double quote$((OPTIND -1))? Isn't the result of an arithmetic expression always a number?
– user000001
Dec 12 at 17:43
2
@user000001 Yes, and$IFSmay include digits. which means that the number could be split into multiple words/numbers. Test withn=123; ( IFS=13; echo $n ).
– Kusalananda
Dec 12 at 17:45
Thant's interesting, never thought of that case
– user000001
Dec 12 at 17:47
@user000001 Very few does. Fortunately, most shells resetIFSfor each new shell invocation.dashdoes not, so potentially one couldexport IFS=0123456789before running a/bin/shshell script on Unices whereshisdashjust to see in what way it breaks.
– Kusalananda
Dec 12 at 17:48
I more benign example might be someone settingIFS=-to split something on dashes, and then not resetting it, causing the leading minus sign to be lost. Arguably the bug would be caused by not resetting the original value ofIFSand not by the lack of quotes, but I guess it never hurts to program defensively.
– user000001
Dec 12 at 18:02
Why double quote
$((OPTIND -1))? Isn't the result of an arithmetic expression always a number?– user000001
Dec 12 at 17:43
Why double quote
$((OPTIND -1))? Isn't the result of an arithmetic expression always a number?– user000001
Dec 12 at 17:43
2
2
@user000001 Yes, and
$IFS may include digits. which means that the number could be split into multiple words/numbers. Test with n=123; ( IFS=13; echo $n ).– Kusalananda
Dec 12 at 17:45
@user000001 Yes, and
$IFS may include digits. which means that the number could be split into multiple words/numbers. Test with n=123; ( IFS=13; echo $n ).– Kusalananda
Dec 12 at 17:45
Thant's interesting, never thought of that case
– user000001
Dec 12 at 17:47
Thant's interesting, never thought of that case
– user000001
Dec 12 at 17:47
@user000001 Very few does. Fortunately, most shells reset
IFS for each new shell invocation. dash does not, so potentially one could export IFS=0123456789 before running a /bin/sh shell script on Unices where sh is dash just to see in what way it breaks.– Kusalananda
Dec 12 at 17:48
@user000001 Very few does. Fortunately, most shells reset
IFS for each new shell invocation. dash does not, so potentially one could export IFS=0123456789 before running a /bin/sh shell script on Unices where sh is dash just to see in what way it breaks.– Kusalananda
Dec 12 at 17:48
I more benign example might be someone setting
IFS=- to split something on dashes, and then not resetting it, causing the leading minus sign to be lost. Arguably the bug would be caused by not resetting the original value of IFS and not by the lack of quotes, but I guess it never hurts to program defensively.– user000001
Dec 12 at 18:02
I more benign example might be someone setting
IFS=- to split something on dashes, and then not resetting it, causing the leading minus sign to be lost. Arguably the bug would be caused by not resetting the original value of IFS and not by the lack of quotes, but I guess it never hurts to program defensively.– user000001
Dec 12 at 18:02
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f487548%2fgetopts-does-not-seem-to-work%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
