Passing a command with arguments to a script
Clash Royale CLAN TAG#URR8PPP
up vote
6
down vote
favorite
I am trying to write a shell script that receives as an input a command with arguments and runs it.
As an example, I am hoping to use this in cron
as follows:
0 11 * * * my_wrapper.sh "task_name" "command arg1 arg2 arg3 ..."
The details of what my_wrapper.sh
does don't matter, but it is a zsh
script and I want it to receive command arg1 arg2 arg3 ...
and invoke it. Note that the arguments may contain single quotes, double quotes, etc.
What is the proper way of passing and receiving commands with arguments to scripts?
Update:
On the command line in zsh, @Gilles' first solution works great:
#!/bin/zsh
task_name=$1
shift
"$@" > /path/to/logging_directory/$task_name
and then invoking > my_wrapper.sh date "%Y-%b-%d"
from the command line does the job.
However, when I try to use it as follows in cron
:
CRON_WRAPPER="/long/path/to/my_wrapper.sh"
0 11 * * * $CRON_WRAPPER "current_date.log" date "+%Y-%b-%d"
It doesn't work.
Final update (problem solved):
As explained in Gilles' answer, crontab
requires escaping any %
signs. After changing the above to:
CRON_WRAPPER="/long/path/to/my_wrapper.sh"
0 11 * * * $CRON_WRAPPER "current_date.log" date "+%Y-%b-%d"
it worked. All set.
shell zsh
add a comment |Â
up vote
6
down vote
favorite
I am trying to write a shell script that receives as an input a command with arguments and runs it.
As an example, I am hoping to use this in cron
as follows:
0 11 * * * my_wrapper.sh "task_name" "command arg1 arg2 arg3 ..."
The details of what my_wrapper.sh
does don't matter, but it is a zsh
script and I want it to receive command arg1 arg2 arg3 ...
and invoke it. Note that the arguments may contain single quotes, double quotes, etc.
What is the proper way of passing and receiving commands with arguments to scripts?
Update:
On the command line in zsh, @Gilles' first solution works great:
#!/bin/zsh
task_name=$1
shift
"$@" > /path/to/logging_directory/$task_name
and then invoking > my_wrapper.sh date "%Y-%b-%d"
from the command line does the job.
However, when I try to use it as follows in cron
:
CRON_WRAPPER="/long/path/to/my_wrapper.sh"
0 11 * * * $CRON_WRAPPER "current_date.log" date "+%Y-%b-%d"
It doesn't work.
Final update (problem solved):
As explained in Gilles' answer, crontab
requires escaping any %
signs. After changing the above to:
CRON_WRAPPER="/long/path/to/my_wrapper.sh"
0 11 * * * $CRON_WRAPPER "current_date.log" date "+%Y-%b-%d"
it worked. All set.
shell zsh
1
Is there a reason you are trying to pass the command as an argument instead of invoking the command in the script and passing the arguments to it when you run the script?
â cremefraiche
Dec 28 '14 at 5:41
Thanks @cremefraiche. Not sure I follow, but just in case:my_wrapper.sh
is meant to be a generic wrapper for cron jobs. For now it only logs the output on a predefined folder (the folder's name is given by the current date, and the logging filename istask_name
followed by the current timestamp). I also hope to email myself a note saying that the tasktask_name
finished correctly. Are you suggesting to not use a generic wrapper to do all this?
â Amelio Vazquez-Reina
Dec 28 '14 at 19:29
add a comment |Â
up vote
6
down vote
favorite
up vote
6
down vote
favorite
I am trying to write a shell script that receives as an input a command with arguments and runs it.
As an example, I am hoping to use this in cron
as follows:
0 11 * * * my_wrapper.sh "task_name" "command arg1 arg2 arg3 ..."
The details of what my_wrapper.sh
does don't matter, but it is a zsh
script and I want it to receive command arg1 arg2 arg3 ...
and invoke it. Note that the arguments may contain single quotes, double quotes, etc.
What is the proper way of passing and receiving commands with arguments to scripts?
Update:
On the command line in zsh, @Gilles' first solution works great:
#!/bin/zsh
task_name=$1
shift
"$@" > /path/to/logging_directory/$task_name
and then invoking > my_wrapper.sh date "%Y-%b-%d"
from the command line does the job.
However, when I try to use it as follows in cron
:
CRON_WRAPPER="/long/path/to/my_wrapper.sh"
0 11 * * * $CRON_WRAPPER "current_date.log" date "+%Y-%b-%d"
It doesn't work.
Final update (problem solved):
As explained in Gilles' answer, crontab
requires escaping any %
signs. After changing the above to:
CRON_WRAPPER="/long/path/to/my_wrapper.sh"
0 11 * * * $CRON_WRAPPER "current_date.log" date "+%Y-%b-%d"
it worked. All set.
shell zsh
I am trying to write a shell script that receives as an input a command with arguments and runs it.
As an example, I am hoping to use this in cron
as follows:
0 11 * * * my_wrapper.sh "task_name" "command arg1 arg2 arg3 ..."
The details of what my_wrapper.sh
does don't matter, but it is a zsh
script and I want it to receive command arg1 arg2 arg3 ...
and invoke it. Note that the arguments may contain single quotes, double quotes, etc.
What is the proper way of passing and receiving commands with arguments to scripts?
Update:
On the command line in zsh, @Gilles' first solution works great:
#!/bin/zsh
task_name=$1
shift
"$@" > /path/to/logging_directory/$task_name
and then invoking > my_wrapper.sh date "%Y-%b-%d"
from the command line does the job.
However, when I try to use it as follows in cron
:
CRON_WRAPPER="/long/path/to/my_wrapper.sh"
0 11 * * * $CRON_WRAPPER "current_date.log" date "+%Y-%b-%d"
It doesn't work.
Final update (problem solved):
As explained in Gilles' answer, crontab
requires escaping any %
signs. After changing the above to:
CRON_WRAPPER="/long/path/to/my_wrapper.sh"
0 11 * * * $CRON_WRAPPER "current_date.log" date "+%Y-%b-%d"
it worked. All set.
shell zsh
shell zsh
edited Dec 29 '14 at 1:35
asked Dec 28 '14 at 5:24
Amelio Vazquez-Reina
11.9k51124228
11.9k51124228
1
Is there a reason you are trying to pass the command as an argument instead of invoking the command in the script and passing the arguments to it when you run the script?
â cremefraiche
Dec 28 '14 at 5:41
Thanks @cremefraiche. Not sure I follow, but just in case:my_wrapper.sh
is meant to be a generic wrapper for cron jobs. For now it only logs the output on a predefined folder (the folder's name is given by the current date, and the logging filename istask_name
followed by the current timestamp). I also hope to email myself a note saying that the tasktask_name
finished correctly. Are you suggesting to not use a generic wrapper to do all this?
â Amelio Vazquez-Reina
Dec 28 '14 at 19:29
add a comment |Â
1
Is there a reason you are trying to pass the command as an argument instead of invoking the command in the script and passing the arguments to it when you run the script?
â cremefraiche
Dec 28 '14 at 5:41
Thanks @cremefraiche. Not sure I follow, but just in case:my_wrapper.sh
is meant to be a generic wrapper for cron jobs. For now it only logs the output on a predefined folder (the folder's name is given by the current date, and the logging filename istask_name
followed by the current timestamp). I also hope to email myself a note saying that the tasktask_name
finished correctly. Are you suggesting to not use a generic wrapper to do all this?
â Amelio Vazquez-Reina
Dec 28 '14 at 19:29
1
1
Is there a reason you are trying to pass the command as an argument instead of invoking the command in the script and passing the arguments to it when you run the script?
â cremefraiche
Dec 28 '14 at 5:41
Is there a reason you are trying to pass the command as an argument instead of invoking the command in the script and passing the arguments to it when you run the script?
â cremefraiche
Dec 28 '14 at 5:41
Thanks @cremefraiche. Not sure I follow, but just in case:
my_wrapper.sh
is meant to be a generic wrapper for cron jobs. For now it only logs the output on a predefined folder (the folder's name is given by the current date, and the logging filename is task_name
followed by the current timestamp). I also hope to email myself a note saying that the task task_name
finished correctly. Are you suggesting to not use a generic wrapper to do all this?â Amelio Vazquez-Reina
Dec 28 '14 at 19:29
Thanks @cremefraiche. Not sure I follow, but just in case:
my_wrapper.sh
is meant to be a generic wrapper for cron jobs. For now it only logs the output on a predefined folder (the folder's name is given by the current date, and the logging filename is task_name
followed by the current timestamp). I also hope to email myself a note saying that the task task_name
finished correctly. Are you suggesting to not use a generic wrapper to do all this?â Amelio Vazquez-Reina
Dec 28 '14 at 19:29
add a comment |Â
3 Answers
3
active
oldest
votes
up vote
3
down vote
accepted
You have two choices: you can pass a program to execute with some arguments, or you can pass a shell script. Both concepts can be called âÂÂa commandâÂÂ.
A program with some arguments takes the form of a list of strings, the first of which is the path to an executable file (or a name not containing any slash, to be looked up in the list of directories indicated by the PATH
environment variable). This has the advantage that the user can pass arguments to that command without worrying about quoting; the user can invoke a shell explicitly (sh -c â¦
if they want). If you choose this, pass each string (the program and its argument) as a separate argument to your script. These would typically be the last arguments to your script (if you want to be able to pass more arguments, you need to designate a special string as an end-of-program-arguments marker, which you then can't pass to the program unless you make the syntax even more complicated).
0 11 * * * my_wrapper.sh "task_name" command arg1 arg2 arg3 ...
and in your script:
#!/bin/zsh
task_name=$1
shift
"$@"
A shell script is a string that you pass to the sh
program for execution. This allows the user to write any shell snippet without having to explicitly invoke a shell, and is simpler to parse since it's a single string, hence a single argument to your program. In an sh
script, you could call eval
, but don't do this in zsh, because users wouldn't expect to have to write zsh syntax which is a little different from sh syntax.
0 11 * * * my_wrapper.sh "task_name" "command arg1 arg2 arg3 ..."
and in your script:
#!/bin/zsh
task_name=$1
sh -c "$2"
Thanks @Gilles, your first solution works well, but does not seem to work well when using parameter expansion incron
. Really odd. I added an update to the OP to reflect this.
â Amelio Vazquez-Reina
Dec 29 '14 at 0:37
2
@user815423426 You need to quote the percent signs for cron.
â Gilles
Dec 29 '14 at 0:49
Thanks. Apparently that isn't the problem (I quoted the argument in the update to the OP) I have the same problem after quoting the percent signs, or with e.g.python -c "2+2"
â Amelio Vazquez-Reina
Dec 29 '14 at 0:51
2
@user815423426 I don't see anything obviously wrong. Addset -x; : "$^@"
at the top of the script to get a debugging trace and post the content of the email that cron sends you.
â Gilles
Dec 29 '14 at 1:03
I just realized that the link asks to escape the percent sign. I was quoting things asdate "+%Y-%b-%d"
I should have read your link better. All set!
â Amelio Vazquez-Reina
Dec 29 '14 at 1:33
add a comment |Â
up vote
4
down vote
The best way to handle this is to pass the actual command args to your wrapper as args instead of as a string. You can call your wrapper like this:
my_wrapper "task_name" command arg1 arg2 arg3
my_wrapper
would contain the following:
task_name=$1
shift # remove the task_name from the command+args
"$@" # execute the command with args, while preserving spaces etc
Thanks, if I trymy_wrapper "get_date" date '+%d'
, it tries to invokedate +%d
(it drops the single quotes), so thedate
command fails (I know this in part because I enabledset -x
on the receiving script). Hmm... I wonder if this answer to this question: Running commands stored in shell variables can help.
â Amelio Vazquez-Reina
Dec 28 '14 at 21:07
1
I'm afraid there is no nice way around the single quote problem. Bash will parse single quotes, which means those quotes will not exist in your wrapper script. You would need to escape the quotes in date +'%d'
â bbaja42
Dec 29 '14 at 0:40
add a comment |Â
up vote
1
down vote
I was having I think a similar issue with dash options and I came across this question here in my searching so I wanted to share what helped me. I was using the following crontab:
0 23 * * * sudo -u myname /home/myname/bin/buildme.sh -f >> /home/myname/log.txt
And inside the bash script I was using this to get the -f option:
while getopts ":f" opt; do
case $opt in
f)
force_full=1
;;
?)
echo "Invalid option: -$OPTARG" >&2
;;
esac
done
So I noticed that the option wasn't being honored when I ran this through cron for some reason. Well, adding /bin/bash to the cronjob fixed it right up. The new crontab is:
0 23 * * * sudo -u myname /bin/bash /home/myname/bin/buildme.sh -f >> /home/myname/log.txt
New contributor
add a comment |Â
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
3
down vote
accepted
You have two choices: you can pass a program to execute with some arguments, or you can pass a shell script. Both concepts can be called âÂÂa commandâÂÂ.
A program with some arguments takes the form of a list of strings, the first of which is the path to an executable file (or a name not containing any slash, to be looked up in the list of directories indicated by the PATH
environment variable). This has the advantage that the user can pass arguments to that command without worrying about quoting; the user can invoke a shell explicitly (sh -c â¦
if they want). If you choose this, pass each string (the program and its argument) as a separate argument to your script. These would typically be the last arguments to your script (if you want to be able to pass more arguments, you need to designate a special string as an end-of-program-arguments marker, which you then can't pass to the program unless you make the syntax even more complicated).
0 11 * * * my_wrapper.sh "task_name" command arg1 arg2 arg3 ...
and in your script:
#!/bin/zsh
task_name=$1
shift
"$@"
A shell script is a string that you pass to the sh
program for execution. This allows the user to write any shell snippet without having to explicitly invoke a shell, and is simpler to parse since it's a single string, hence a single argument to your program. In an sh
script, you could call eval
, but don't do this in zsh, because users wouldn't expect to have to write zsh syntax which is a little different from sh syntax.
0 11 * * * my_wrapper.sh "task_name" "command arg1 arg2 arg3 ..."
and in your script:
#!/bin/zsh
task_name=$1
sh -c "$2"
Thanks @Gilles, your first solution works well, but does not seem to work well when using parameter expansion incron
. Really odd. I added an update to the OP to reflect this.
â Amelio Vazquez-Reina
Dec 29 '14 at 0:37
2
@user815423426 You need to quote the percent signs for cron.
â Gilles
Dec 29 '14 at 0:49
Thanks. Apparently that isn't the problem (I quoted the argument in the update to the OP) I have the same problem after quoting the percent signs, or with e.g.python -c "2+2"
â Amelio Vazquez-Reina
Dec 29 '14 at 0:51
2
@user815423426 I don't see anything obviously wrong. Addset -x; : "$^@"
at the top of the script to get a debugging trace and post the content of the email that cron sends you.
â Gilles
Dec 29 '14 at 1:03
I just realized that the link asks to escape the percent sign. I was quoting things asdate "+%Y-%b-%d"
I should have read your link better. All set!
â Amelio Vazquez-Reina
Dec 29 '14 at 1:33
add a comment |Â
up vote
3
down vote
accepted
You have two choices: you can pass a program to execute with some arguments, or you can pass a shell script. Both concepts can be called âÂÂa commandâÂÂ.
A program with some arguments takes the form of a list of strings, the first of which is the path to an executable file (or a name not containing any slash, to be looked up in the list of directories indicated by the PATH
environment variable). This has the advantage that the user can pass arguments to that command without worrying about quoting; the user can invoke a shell explicitly (sh -c â¦
if they want). If you choose this, pass each string (the program and its argument) as a separate argument to your script. These would typically be the last arguments to your script (if you want to be able to pass more arguments, you need to designate a special string as an end-of-program-arguments marker, which you then can't pass to the program unless you make the syntax even more complicated).
0 11 * * * my_wrapper.sh "task_name" command arg1 arg2 arg3 ...
and in your script:
#!/bin/zsh
task_name=$1
shift
"$@"
A shell script is a string that you pass to the sh
program for execution. This allows the user to write any shell snippet without having to explicitly invoke a shell, and is simpler to parse since it's a single string, hence a single argument to your program. In an sh
script, you could call eval
, but don't do this in zsh, because users wouldn't expect to have to write zsh syntax which is a little different from sh syntax.
0 11 * * * my_wrapper.sh "task_name" "command arg1 arg2 arg3 ..."
and in your script:
#!/bin/zsh
task_name=$1
sh -c "$2"
Thanks @Gilles, your first solution works well, but does not seem to work well when using parameter expansion incron
. Really odd. I added an update to the OP to reflect this.
â Amelio Vazquez-Reina
Dec 29 '14 at 0:37
2
@user815423426 You need to quote the percent signs for cron.
â Gilles
Dec 29 '14 at 0:49
Thanks. Apparently that isn't the problem (I quoted the argument in the update to the OP) I have the same problem after quoting the percent signs, or with e.g.python -c "2+2"
â Amelio Vazquez-Reina
Dec 29 '14 at 0:51
2
@user815423426 I don't see anything obviously wrong. Addset -x; : "$^@"
at the top of the script to get a debugging trace and post the content of the email that cron sends you.
â Gilles
Dec 29 '14 at 1:03
I just realized that the link asks to escape the percent sign. I was quoting things asdate "+%Y-%b-%d"
I should have read your link better. All set!
â Amelio Vazquez-Reina
Dec 29 '14 at 1:33
add a comment |Â
up vote
3
down vote
accepted
up vote
3
down vote
accepted
You have two choices: you can pass a program to execute with some arguments, or you can pass a shell script. Both concepts can be called âÂÂa commandâÂÂ.
A program with some arguments takes the form of a list of strings, the first of which is the path to an executable file (or a name not containing any slash, to be looked up in the list of directories indicated by the PATH
environment variable). This has the advantage that the user can pass arguments to that command without worrying about quoting; the user can invoke a shell explicitly (sh -c â¦
if they want). If you choose this, pass each string (the program and its argument) as a separate argument to your script. These would typically be the last arguments to your script (if you want to be able to pass more arguments, you need to designate a special string as an end-of-program-arguments marker, which you then can't pass to the program unless you make the syntax even more complicated).
0 11 * * * my_wrapper.sh "task_name" command arg1 arg2 arg3 ...
and in your script:
#!/bin/zsh
task_name=$1
shift
"$@"
A shell script is a string that you pass to the sh
program for execution. This allows the user to write any shell snippet without having to explicitly invoke a shell, and is simpler to parse since it's a single string, hence a single argument to your program. In an sh
script, you could call eval
, but don't do this in zsh, because users wouldn't expect to have to write zsh syntax which is a little different from sh syntax.
0 11 * * * my_wrapper.sh "task_name" "command arg1 arg2 arg3 ..."
and in your script:
#!/bin/zsh
task_name=$1
sh -c "$2"
You have two choices: you can pass a program to execute with some arguments, or you can pass a shell script. Both concepts can be called âÂÂa commandâÂÂ.
A program with some arguments takes the form of a list of strings, the first of which is the path to an executable file (or a name not containing any slash, to be looked up in the list of directories indicated by the PATH
environment variable). This has the advantage that the user can pass arguments to that command without worrying about quoting; the user can invoke a shell explicitly (sh -c â¦
if they want). If you choose this, pass each string (the program and its argument) as a separate argument to your script. These would typically be the last arguments to your script (if you want to be able to pass more arguments, you need to designate a special string as an end-of-program-arguments marker, which you then can't pass to the program unless you make the syntax even more complicated).
0 11 * * * my_wrapper.sh "task_name" command arg1 arg2 arg3 ...
and in your script:
#!/bin/zsh
task_name=$1
shift
"$@"
A shell script is a string that you pass to the sh
program for execution. This allows the user to write any shell snippet without having to explicitly invoke a shell, and is simpler to parse since it's a single string, hence a single argument to your program. In an sh
script, you could call eval
, but don't do this in zsh, because users wouldn't expect to have to write zsh syntax which is a little different from sh syntax.
0 11 * * * my_wrapper.sh "task_name" "command arg1 arg2 arg3 ..."
and in your script:
#!/bin/zsh
task_name=$1
sh -c "$2"
answered Dec 28 '14 at 23:29
Gilles
513k12010161547
513k12010161547
Thanks @Gilles, your first solution works well, but does not seem to work well when using parameter expansion incron
. Really odd. I added an update to the OP to reflect this.
â Amelio Vazquez-Reina
Dec 29 '14 at 0:37
2
@user815423426 You need to quote the percent signs for cron.
â Gilles
Dec 29 '14 at 0:49
Thanks. Apparently that isn't the problem (I quoted the argument in the update to the OP) I have the same problem after quoting the percent signs, or with e.g.python -c "2+2"
â Amelio Vazquez-Reina
Dec 29 '14 at 0:51
2
@user815423426 I don't see anything obviously wrong. Addset -x; : "$^@"
at the top of the script to get a debugging trace and post the content of the email that cron sends you.
â Gilles
Dec 29 '14 at 1:03
I just realized that the link asks to escape the percent sign. I was quoting things asdate "+%Y-%b-%d"
I should have read your link better. All set!
â Amelio Vazquez-Reina
Dec 29 '14 at 1:33
add a comment |Â
Thanks @Gilles, your first solution works well, but does not seem to work well when using parameter expansion incron
. Really odd. I added an update to the OP to reflect this.
â Amelio Vazquez-Reina
Dec 29 '14 at 0:37
2
@user815423426 You need to quote the percent signs for cron.
â Gilles
Dec 29 '14 at 0:49
Thanks. Apparently that isn't the problem (I quoted the argument in the update to the OP) I have the same problem after quoting the percent signs, or with e.g.python -c "2+2"
â Amelio Vazquez-Reina
Dec 29 '14 at 0:51
2
@user815423426 I don't see anything obviously wrong. Addset -x; : "$^@"
at the top of the script to get a debugging trace and post the content of the email that cron sends you.
â Gilles
Dec 29 '14 at 1:03
I just realized that the link asks to escape the percent sign. I was quoting things asdate "+%Y-%b-%d"
I should have read your link better. All set!
â Amelio Vazquez-Reina
Dec 29 '14 at 1:33
Thanks @Gilles, your first solution works well, but does not seem to work well when using parameter expansion in
cron
. Really odd. I added an update to the OP to reflect this.â Amelio Vazquez-Reina
Dec 29 '14 at 0:37
Thanks @Gilles, your first solution works well, but does not seem to work well when using parameter expansion in
cron
. Really odd. I added an update to the OP to reflect this.â Amelio Vazquez-Reina
Dec 29 '14 at 0:37
2
2
@user815423426 You need to quote the percent signs for cron.
â Gilles
Dec 29 '14 at 0:49
@user815423426 You need to quote the percent signs for cron.
â Gilles
Dec 29 '14 at 0:49
Thanks. Apparently that isn't the problem (I quoted the argument in the update to the OP) I have the same problem after quoting the percent signs, or with e.g.
python -c "2+2"
â Amelio Vazquez-Reina
Dec 29 '14 at 0:51
Thanks. Apparently that isn't the problem (I quoted the argument in the update to the OP) I have the same problem after quoting the percent signs, or with e.g.
python -c "2+2"
â Amelio Vazquez-Reina
Dec 29 '14 at 0:51
2
2
@user815423426 I don't see anything obviously wrong. Add
set -x; : "$^@"
at the top of the script to get a debugging trace and post the content of the email that cron sends you.â Gilles
Dec 29 '14 at 1:03
@user815423426 I don't see anything obviously wrong. Add
set -x; : "$^@"
at the top of the script to get a debugging trace and post the content of the email that cron sends you.â Gilles
Dec 29 '14 at 1:03
I just realized that the link asks to escape the percent sign. I was quoting things as
date "+%Y-%b-%d"
I should have read your link better. All set!â Amelio Vazquez-Reina
Dec 29 '14 at 1:33
I just realized that the link asks to escape the percent sign. I was quoting things as
date "+%Y-%b-%d"
I should have read your link better. All set!â Amelio Vazquez-Reina
Dec 29 '14 at 1:33
add a comment |Â
up vote
4
down vote
The best way to handle this is to pass the actual command args to your wrapper as args instead of as a string. You can call your wrapper like this:
my_wrapper "task_name" command arg1 arg2 arg3
my_wrapper
would contain the following:
task_name=$1
shift # remove the task_name from the command+args
"$@" # execute the command with args, while preserving spaces etc
Thanks, if I trymy_wrapper "get_date" date '+%d'
, it tries to invokedate +%d
(it drops the single quotes), so thedate
command fails (I know this in part because I enabledset -x
on the receiving script). Hmm... I wonder if this answer to this question: Running commands stored in shell variables can help.
â Amelio Vazquez-Reina
Dec 28 '14 at 21:07
1
I'm afraid there is no nice way around the single quote problem. Bash will parse single quotes, which means those quotes will not exist in your wrapper script. You would need to escape the quotes in date +'%d'
â bbaja42
Dec 29 '14 at 0:40
add a comment |Â
up vote
4
down vote
The best way to handle this is to pass the actual command args to your wrapper as args instead of as a string. You can call your wrapper like this:
my_wrapper "task_name" command arg1 arg2 arg3
my_wrapper
would contain the following:
task_name=$1
shift # remove the task_name from the command+args
"$@" # execute the command with args, while preserving spaces etc
Thanks, if I trymy_wrapper "get_date" date '+%d'
, it tries to invokedate +%d
(it drops the single quotes), so thedate
command fails (I know this in part because I enabledset -x
on the receiving script). Hmm... I wonder if this answer to this question: Running commands stored in shell variables can help.
â Amelio Vazquez-Reina
Dec 28 '14 at 21:07
1
I'm afraid there is no nice way around the single quote problem. Bash will parse single quotes, which means those quotes will not exist in your wrapper script. You would need to escape the quotes in date +'%d'
â bbaja42
Dec 29 '14 at 0:40
add a comment |Â
up vote
4
down vote
up vote
4
down vote
The best way to handle this is to pass the actual command args to your wrapper as args instead of as a string. You can call your wrapper like this:
my_wrapper "task_name" command arg1 arg2 arg3
my_wrapper
would contain the following:
task_name=$1
shift # remove the task_name from the command+args
"$@" # execute the command with args, while preserving spaces etc
The best way to handle this is to pass the actual command args to your wrapper as args instead of as a string. You can call your wrapper like this:
my_wrapper "task_name" command arg1 arg2 arg3
my_wrapper
would contain the following:
task_name=$1
shift # remove the task_name from the command+args
"$@" # execute the command with args, while preserving spaces etc
answered Dec 28 '14 at 5:56
jordanm
29.3k27891
29.3k27891
Thanks, if I trymy_wrapper "get_date" date '+%d'
, it tries to invokedate +%d
(it drops the single quotes), so thedate
command fails (I know this in part because I enabledset -x
on the receiving script). Hmm... I wonder if this answer to this question: Running commands stored in shell variables can help.
â Amelio Vazquez-Reina
Dec 28 '14 at 21:07
1
I'm afraid there is no nice way around the single quote problem. Bash will parse single quotes, which means those quotes will not exist in your wrapper script. You would need to escape the quotes in date +'%d'
â bbaja42
Dec 29 '14 at 0:40
add a comment |Â
Thanks, if I trymy_wrapper "get_date" date '+%d'
, it tries to invokedate +%d
(it drops the single quotes), so thedate
command fails (I know this in part because I enabledset -x
on the receiving script). Hmm... I wonder if this answer to this question: Running commands stored in shell variables can help.
â Amelio Vazquez-Reina
Dec 28 '14 at 21:07
1
I'm afraid there is no nice way around the single quote problem. Bash will parse single quotes, which means those quotes will not exist in your wrapper script. You would need to escape the quotes in date +'%d'
â bbaja42
Dec 29 '14 at 0:40
Thanks, if I try
my_wrapper "get_date" date '+%d'
, it tries to invoke date +%d
(it drops the single quotes), so the date
command fails (I know this in part because I enabled set -x
on the receiving script). Hmm... I wonder if this answer to this question: Running commands stored in shell variables can help.â Amelio Vazquez-Reina
Dec 28 '14 at 21:07
Thanks, if I try
my_wrapper "get_date" date '+%d'
, it tries to invoke date +%d
(it drops the single quotes), so the date
command fails (I know this in part because I enabled set -x
on the receiving script). Hmm... I wonder if this answer to this question: Running commands stored in shell variables can help.â Amelio Vazquez-Reina
Dec 28 '14 at 21:07
1
1
I'm afraid there is no nice way around the single quote problem. Bash will parse single quotes, which means those quotes will not exist in your wrapper script. You would need to escape the quotes in date +'%d'
â bbaja42
Dec 29 '14 at 0:40
I'm afraid there is no nice way around the single quote problem. Bash will parse single quotes, which means those quotes will not exist in your wrapper script. You would need to escape the quotes in date +'%d'
â bbaja42
Dec 29 '14 at 0:40
add a comment |Â
up vote
1
down vote
I was having I think a similar issue with dash options and I came across this question here in my searching so I wanted to share what helped me. I was using the following crontab:
0 23 * * * sudo -u myname /home/myname/bin/buildme.sh -f >> /home/myname/log.txt
And inside the bash script I was using this to get the -f option:
while getopts ":f" opt; do
case $opt in
f)
force_full=1
;;
?)
echo "Invalid option: -$OPTARG" >&2
;;
esac
done
So I noticed that the option wasn't being honored when I ran this through cron for some reason. Well, adding /bin/bash to the cronjob fixed it right up. The new crontab is:
0 23 * * * sudo -u myname /bin/bash /home/myname/bin/buildme.sh -f >> /home/myname/log.txt
New contributor
add a comment |Â
up vote
1
down vote
I was having I think a similar issue with dash options and I came across this question here in my searching so I wanted to share what helped me. I was using the following crontab:
0 23 * * * sudo -u myname /home/myname/bin/buildme.sh -f >> /home/myname/log.txt
And inside the bash script I was using this to get the -f option:
while getopts ":f" opt; do
case $opt in
f)
force_full=1
;;
?)
echo "Invalid option: -$OPTARG" >&2
;;
esac
done
So I noticed that the option wasn't being honored when I ran this through cron for some reason. Well, adding /bin/bash to the cronjob fixed it right up. The new crontab is:
0 23 * * * sudo -u myname /bin/bash /home/myname/bin/buildme.sh -f >> /home/myname/log.txt
New contributor
add a comment |Â
up vote
1
down vote
up vote
1
down vote
I was having I think a similar issue with dash options and I came across this question here in my searching so I wanted to share what helped me. I was using the following crontab:
0 23 * * * sudo -u myname /home/myname/bin/buildme.sh -f >> /home/myname/log.txt
And inside the bash script I was using this to get the -f option:
while getopts ":f" opt; do
case $opt in
f)
force_full=1
;;
?)
echo "Invalid option: -$OPTARG" >&2
;;
esac
done
So I noticed that the option wasn't being honored when I ran this through cron for some reason. Well, adding /bin/bash to the cronjob fixed it right up. The new crontab is:
0 23 * * * sudo -u myname /bin/bash /home/myname/bin/buildme.sh -f >> /home/myname/log.txt
New contributor
I was having I think a similar issue with dash options and I came across this question here in my searching so I wanted to share what helped me. I was using the following crontab:
0 23 * * * sudo -u myname /home/myname/bin/buildme.sh -f >> /home/myname/log.txt
And inside the bash script I was using this to get the -f option:
while getopts ":f" opt; do
case $opt in
f)
force_full=1
;;
?)
echo "Invalid option: -$OPTARG" >&2
;;
esac
done
So I noticed that the option wasn't being honored when I ran this through cron for some reason. Well, adding /bin/bash to the cronjob fixed it right up. The new crontab is:
0 23 * * * sudo -u myname /bin/bash /home/myname/bin/buildme.sh -f >> /home/myname/log.txt
New contributor
New contributor
answered yesterday
Eradicatore
1112
1112
New contributor
New contributor
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%2f176226%2fpassing-a-command-with-arguments-to-a-script%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
1
Is there a reason you are trying to pass the command as an argument instead of invoking the command in the script and passing the arguments to it when you run the script?
â cremefraiche
Dec 28 '14 at 5:41
Thanks @cremefraiche. Not sure I follow, but just in case:
my_wrapper.sh
is meant to be a generic wrapper for cron jobs. For now it only logs the output on a predefined folder (the folder's name is given by the current date, and the logging filename istask_name
followed by the current timestamp). I also hope to email myself a note saying that the tasktask_name
finished correctly. Are you suggesting to not use a generic wrapper to do all this?â Amelio Vazquez-Reina
Dec 28 '14 at 19:29