What is the purpose of the very first character of the option-string of getopts being a : (colon)?
Clash Royale CLAN TAG#URR8PPP
up vote
1
down vote
favorite
In option string when using getopts
, from http://wiki.bash-hackers.org/howto/getopts_tutorial
If the very first character of the option-string is a : (colon), which would normally be nonsense because there's no
option letter preceding it, getopts switches to " silent error reporting mode". In productive scripts, this is usually
what you want because it allows you to handle errors yourself without being disturbed by annoying messages.
I was wondering what the followings mean:
"silent error reporting mode"
"it allows you to handle errors yourself without being disturbed by annoying messages"?
Could you maybe give some examples?
Thanks.
bash getopts
add a comment |Â
up vote
1
down vote
favorite
In option string when using getopts
, from http://wiki.bash-hackers.org/howto/getopts_tutorial
If the very first character of the option-string is a : (colon), which would normally be nonsense because there's no
option letter preceding it, getopts switches to " silent error reporting mode". In productive scripts, this is usually
what you want because it allows you to handle errors yourself without being disturbed by annoying messages.
I was wondering what the followings mean:
"silent error reporting mode"
"it allows you to handle errors yourself without being disturbed by annoying messages"?
Could you maybe give some examples?
Thanks.
bash getopts
add a comment |Â
up vote
1
down vote
favorite
up vote
1
down vote
favorite
In option string when using getopts
, from http://wiki.bash-hackers.org/howto/getopts_tutorial
If the very first character of the option-string is a : (colon), which would normally be nonsense because there's no
option letter preceding it, getopts switches to " silent error reporting mode". In productive scripts, this is usually
what you want because it allows you to handle errors yourself without being disturbed by annoying messages.
I was wondering what the followings mean:
"silent error reporting mode"
"it allows you to handle errors yourself without being disturbed by annoying messages"?
Could you maybe give some examples?
Thanks.
bash getopts
In option string when using getopts
, from http://wiki.bash-hackers.org/howto/getopts_tutorial
If the very first character of the option-string is a : (colon), which would normally be nonsense because there's no
option letter preceding it, getopts switches to " silent error reporting mode". In productive scripts, this is usually
what you want because it allows you to handle errors yourself without being disturbed by annoying messages.
I was wondering what the followings mean:
"silent error reporting mode"
"it allows you to handle errors yourself without being disturbed by annoying messages"?
Could you maybe give some examples?
Thanks.
bash getopts
asked Feb 25 at 16:15
Tim
22.7k64224401
22.7k64224401
add a comment |Â
add a comment |Â
2 Answers
2
active
oldest
votes
up vote
1
down vote
accepted
If the very first character of optstring
is a colon, getopts
will not produce any diagnostic messages for missing option arguments or invalid options.
This could be useful if you really need to have more control over the diagnostic messages produced by your script or if you simply don't want anything to appear on the standard error stream if the user provides wonky command line options.
In silent reporting mode, if you want to alert the user of an invalid option, you will have to look for ?
in the variable passed to getopts
. Likewise, for missing option arguments, it's a :
. These are the two errors usually handled by getopts
itself, but to do your own error reporting to the user, you will need to catch these separately to be able to give the correct diagnostic message.
In non-silent reporting mode, getopts
does its own error reporting on standard error and you just have to catch a *
for "any error".
Compare these two examples:
#!/bin/bash
while getopts 'a:b:' opt; do
case "$opt" in
a) printf 'Got a: "%s"n' "$OPTARG" ;;
b) printf 'Got b: "%s"n' "$OPTARG" ;;
*) echo 'some kind of error' >&2
exit 1
esac
done
$ bash script.sh -a
script.sh: option requires an argument -- a
some kind of error
#!/bin/bash
while getopts ':a:b:' opt; do
case "$opt" in
a) printf 'Got a: "%s"n' "$OPTARG" ;;
b) printf 'Got b: "%s"n' "$OPTARG" ;;
:) echo 'missing argument!' >&2
exit 1 ;;
?) echo 'invalid option!' >&2
exit
esac
done
$ bash script.sh -a
missing argument!
add a comment |Â
up vote
1
down vote
Non-silent, getopts
prints an error message:
$ bash -c 'getopts a opt' getopts_test -b
getopts_test: illegal option -- b
Silent, getopts
doesn't print it by itself:
$ bash -c 'getopts :a opt' getopts_test -b
$
So with the colon for silent mode, we can print our own error in the script just the way we like it, instead of the fixed message:
#!/bin/bash
while getopts :a opt; do
[[ $opt = "?" ]] && echo "Invalid option character '$OPTARG'" >&2;
done
add a comment |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
accepted
If the very first character of optstring
is a colon, getopts
will not produce any diagnostic messages for missing option arguments or invalid options.
This could be useful if you really need to have more control over the diagnostic messages produced by your script or if you simply don't want anything to appear on the standard error stream if the user provides wonky command line options.
In silent reporting mode, if you want to alert the user of an invalid option, you will have to look for ?
in the variable passed to getopts
. Likewise, for missing option arguments, it's a :
. These are the two errors usually handled by getopts
itself, but to do your own error reporting to the user, you will need to catch these separately to be able to give the correct diagnostic message.
In non-silent reporting mode, getopts
does its own error reporting on standard error and you just have to catch a *
for "any error".
Compare these two examples:
#!/bin/bash
while getopts 'a:b:' opt; do
case "$opt" in
a) printf 'Got a: "%s"n' "$OPTARG" ;;
b) printf 'Got b: "%s"n' "$OPTARG" ;;
*) echo 'some kind of error' >&2
exit 1
esac
done
$ bash script.sh -a
script.sh: option requires an argument -- a
some kind of error
#!/bin/bash
while getopts ':a:b:' opt; do
case "$opt" in
a) printf 'Got a: "%s"n' "$OPTARG" ;;
b) printf 'Got b: "%s"n' "$OPTARG" ;;
:) echo 'missing argument!' >&2
exit 1 ;;
?) echo 'invalid option!' >&2
exit
esac
done
$ bash script.sh -a
missing argument!
add a comment |Â
up vote
1
down vote
accepted
If the very first character of optstring
is a colon, getopts
will not produce any diagnostic messages for missing option arguments or invalid options.
This could be useful if you really need to have more control over the diagnostic messages produced by your script or if you simply don't want anything to appear on the standard error stream if the user provides wonky command line options.
In silent reporting mode, if you want to alert the user of an invalid option, you will have to look for ?
in the variable passed to getopts
. Likewise, for missing option arguments, it's a :
. These are the two errors usually handled by getopts
itself, but to do your own error reporting to the user, you will need to catch these separately to be able to give the correct diagnostic message.
In non-silent reporting mode, getopts
does its own error reporting on standard error and you just have to catch a *
for "any error".
Compare these two examples:
#!/bin/bash
while getopts 'a:b:' opt; do
case "$opt" in
a) printf 'Got a: "%s"n' "$OPTARG" ;;
b) printf 'Got b: "%s"n' "$OPTARG" ;;
*) echo 'some kind of error' >&2
exit 1
esac
done
$ bash script.sh -a
script.sh: option requires an argument -- a
some kind of error
#!/bin/bash
while getopts ':a:b:' opt; do
case "$opt" in
a) printf 'Got a: "%s"n' "$OPTARG" ;;
b) printf 'Got b: "%s"n' "$OPTARG" ;;
:) echo 'missing argument!' >&2
exit 1 ;;
?) echo 'invalid option!' >&2
exit
esac
done
$ bash script.sh -a
missing argument!
add a comment |Â
up vote
1
down vote
accepted
up vote
1
down vote
accepted
If the very first character of optstring
is a colon, getopts
will not produce any diagnostic messages for missing option arguments or invalid options.
This could be useful if you really need to have more control over the diagnostic messages produced by your script or if you simply don't want anything to appear on the standard error stream if the user provides wonky command line options.
In silent reporting mode, if you want to alert the user of an invalid option, you will have to look for ?
in the variable passed to getopts
. Likewise, for missing option arguments, it's a :
. These are the two errors usually handled by getopts
itself, but to do your own error reporting to the user, you will need to catch these separately to be able to give the correct diagnostic message.
In non-silent reporting mode, getopts
does its own error reporting on standard error and you just have to catch a *
for "any error".
Compare these two examples:
#!/bin/bash
while getopts 'a:b:' opt; do
case "$opt" in
a) printf 'Got a: "%s"n' "$OPTARG" ;;
b) printf 'Got b: "%s"n' "$OPTARG" ;;
*) echo 'some kind of error' >&2
exit 1
esac
done
$ bash script.sh -a
script.sh: option requires an argument -- a
some kind of error
#!/bin/bash
while getopts ':a:b:' opt; do
case "$opt" in
a) printf 'Got a: "%s"n' "$OPTARG" ;;
b) printf 'Got b: "%s"n' "$OPTARG" ;;
:) echo 'missing argument!' >&2
exit 1 ;;
?) echo 'invalid option!' >&2
exit
esac
done
$ bash script.sh -a
missing argument!
If the very first character of optstring
is a colon, getopts
will not produce any diagnostic messages for missing option arguments or invalid options.
This could be useful if you really need to have more control over the diagnostic messages produced by your script or if you simply don't want anything to appear on the standard error stream if the user provides wonky command line options.
In silent reporting mode, if you want to alert the user of an invalid option, you will have to look for ?
in the variable passed to getopts
. Likewise, for missing option arguments, it's a :
. These are the two errors usually handled by getopts
itself, but to do your own error reporting to the user, you will need to catch these separately to be able to give the correct diagnostic message.
In non-silent reporting mode, getopts
does its own error reporting on standard error and you just have to catch a *
for "any error".
Compare these two examples:
#!/bin/bash
while getopts 'a:b:' opt; do
case "$opt" in
a) printf 'Got a: "%s"n' "$OPTARG" ;;
b) printf 'Got b: "%s"n' "$OPTARG" ;;
*) echo 'some kind of error' >&2
exit 1
esac
done
$ bash script.sh -a
script.sh: option requires an argument -- a
some kind of error
#!/bin/bash
while getopts ':a:b:' opt; do
case "$opt" in
a) printf 'Got a: "%s"n' "$OPTARG" ;;
b) printf 'Got b: "%s"n' "$OPTARG" ;;
:) echo 'missing argument!' >&2
exit 1 ;;
?) echo 'invalid option!' >&2
exit
esac
done
$ bash script.sh -a
missing argument!
edited Feb 25 at 16:36
answered Feb 25 at 16:30
Kusalananda
103k13202318
103k13202318
add a comment |Â
add a comment |Â
up vote
1
down vote
Non-silent, getopts
prints an error message:
$ bash -c 'getopts a opt' getopts_test -b
getopts_test: illegal option -- b
Silent, getopts
doesn't print it by itself:
$ bash -c 'getopts :a opt' getopts_test -b
$
So with the colon for silent mode, we can print our own error in the script just the way we like it, instead of the fixed message:
#!/bin/bash
while getopts :a opt; do
[[ $opt = "?" ]] && echo "Invalid option character '$OPTARG'" >&2;
done
add a comment |Â
up vote
1
down vote
Non-silent, getopts
prints an error message:
$ bash -c 'getopts a opt' getopts_test -b
getopts_test: illegal option -- b
Silent, getopts
doesn't print it by itself:
$ bash -c 'getopts :a opt' getopts_test -b
$
So with the colon for silent mode, we can print our own error in the script just the way we like it, instead of the fixed message:
#!/bin/bash
while getopts :a opt; do
[[ $opt = "?" ]] && echo "Invalid option character '$OPTARG'" >&2;
done
add a comment |Â
up vote
1
down vote
up vote
1
down vote
Non-silent, getopts
prints an error message:
$ bash -c 'getopts a opt' getopts_test -b
getopts_test: illegal option -- b
Silent, getopts
doesn't print it by itself:
$ bash -c 'getopts :a opt' getopts_test -b
$
So with the colon for silent mode, we can print our own error in the script just the way we like it, instead of the fixed message:
#!/bin/bash
while getopts :a opt; do
[[ $opt = "?" ]] && echo "Invalid option character '$OPTARG'" >&2;
done
Non-silent, getopts
prints an error message:
$ bash -c 'getopts a opt' getopts_test -b
getopts_test: illegal option -- b
Silent, getopts
doesn't print it by itself:
$ bash -c 'getopts :a opt' getopts_test -b
$
So with the colon for silent mode, we can print our own error in the script just the way we like it, instead of the fixed message:
#!/bin/bash
while getopts :a opt; do
[[ $opt = "?" ]] && echo "Invalid option character '$OPTARG'" >&2;
done
edited Feb 25 at 16:35
answered Feb 25 at 16:28
ilkkachu
49.3k672136
49.3k672136
add a comment |Â
add a comment |Â
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
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f426483%2fwhat-is-the-purpose-of-the-very-first-character-of-the-option-string-of-getopts%23new-answer', 'question_page');
);
Post as a guest
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
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
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