In a shell script, process options like -a -b but leave --abc alone?
up vote
0
down vote
favorite
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
add a comment |
up vote
0
down vote
favorite
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
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 tomy_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." Useshutil.copy2()
for the former andsubprocess.check_call([...])
andsubprocess.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
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
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
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
shell getopts
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 tomy_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." Useshutil.copy2()
for the former andsubprocess.check_call([...])
andsubprocess.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
add a comment |
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 tomy_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." Useshutil.copy2()
for the former andsubprocess.check_call([...])
andsubprocess.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
add a comment |
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 "$@""
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
add a comment |
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)
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
@MikhailRamendikgetopts
parses the options, then prints them in a cleaned-up, standardized format. Theset
command then replaces the passed arguments with the cleaned-up version, so that thewhile
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
add a comment |
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 "$@""
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
add a comment |
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 "$@""
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
add a comment |
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 "$@""
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 "$@""
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
add a comment |
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
add a comment |
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)
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
@MikhailRamendikgetopts
parses the options, then prints them in a cleaned-up, standardized format. Theset
command then replaces the passed arguments with the cleaned-up version, so that thewhile
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
add a comment |
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)
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
@MikhailRamendikgetopts
parses the options, then prints them in a cleaned-up, standardized format. Theset
command then replaces the passed arguments with the cleaned-up version, so that thewhile
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
add a comment |
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)
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)
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
@MikhailRamendikgetopts
parses the options, then prints them in a cleaned-up, standardized format. Theset
command then replaces the passed arguments with the cleaned-up version, so that thewhile
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
add a comment |
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
@MikhailRamendikgetopts
parses the options, then prints them in a cleaned-up, standardized format. Theset
command then replaces the passed arguments with the cleaned-up version, so that thewhile
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
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
Required, but never shown
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
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
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 andsubprocess.check_call([...])
andsubprocess.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