send cron output to a filename that is derived from the program name

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP












1















I tested the following with no luck. Any other ideas?



#cron test, I would like to generate a stderr logfile name based on $0, but $0 value is "/bin/bash"
#why do I want this? Because some program names are quite long, and for standardization
04 10 * * * ~/bin/cron-test >> /tmp/blah 2>>~/.cronlogs/$(basename $0) # $0 is "/bin/bash"
05 10 * * * ~/bin/cron-test >> /tmp/blah 2>>~/.cronlogs/$(basename $1) # $1 is empty?
06 10 * * * ~/bin/cron-test >> /tmp/blah 2>>~/.cronlogs/$(basename $2) # $2 is empty?









share|improve this question



















  • 1





    What is this being run from? What do you expect $0, $1, and $2 to be?

    – Jesse_b
    Feb 21 at 18:40






  • 1





    Better change your script ~/bin/cron-test to redirect its output. There you could use $0 to get the script name.

    – Bodo
    Feb 21 at 18:42











  • Jesse_b, it is supposed to be a cron job. Looking at $1 and $2 is an attempt to work around the fact that $0 does not have the desired value "~/bin/cron-test". I was hoping that $1 would be "-c" and $2 would be "~/bin/cron-test", for example.

    – reikred
    Feb 21 at 19:21












  • Bodo, I do not wish to hardcode output filenames into the script, I want to use stdout and stderr for testing and for non-cron use of the same scripts.

    – reikred
    Feb 21 at 19:23
















1















I tested the following with no luck. Any other ideas?



#cron test, I would like to generate a stderr logfile name based on $0, but $0 value is "/bin/bash"
#why do I want this? Because some program names are quite long, and for standardization
04 10 * * * ~/bin/cron-test >> /tmp/blah 2>>~/.cronlogs/$(basename $0) # $0 is "/bin/bash"
05 10 * * * ~/bin/cron-test >> /tmp/blah 2>>~/.cronlogs/$(basename $1) # $1 is empty?
06 10 * * * ~/bin/cron-test >> /tmp/blah 2>>~/.cronlogs/$(basename $2) # $2 is empty?









share|improve this question



















  • 1





    What is this being run from? What do you expect $0, $1, and $2 to be?

    – Jesse_b
    Feb 21 at 18:40






  • 1





    Better change your script ~/bin/cron-test to redirect its output. There you could use $0 to get the script name.

    – Bodo
    Feb 21 at 18:42











  • Jesse_b, it is supposed to be a cron job. Looking at $1 and $2 is an attempt to work around the fact that $0 does not have the desired value "~/bin/cron-test". I was hoping that $1 would be "-c" and $2 would be "~/bin/cron-test", for example.

    – reikred
    Feb 21 at 19:21












  • Bodo, I do not wish to hardcode output filenames into the script, I want to use stdout and stderr for testing and for non-cron use of the same scripts.

    – reikred
    Feb 21 at 19:23














1












1








1








I tested the following with no luck. Any other ideas?



#cron test, I would like to generate a stderr logfile name based on $0, but $0 value is "/bin/bash"
#why do I want this? Because some program names are quite long, and for standardization
04 10 * * * ~/bin/cron-test >> /tmp/blah 2>>~/.cronlogs/$(basename $0) # $0 is "/bin/bash"
05 10 * * * ~/bin/cron-test >> /tmp/blah 2>>~/.cronlogs/$(basename $1) # $1 is empty?
06 10 * * * ~/bin/cron-test >> /tmp/blah 2>>~/.cronlogs/$(basename $2) # $2 is empty?









share|improve this question
















I tested the following with no luck. Any other ideas?



#cron test, I would like to generate a stderr logfile name based on $0, but $0 value is "/bin/bash"
#why do I want this? Because some program names are quite long, and for standardization
04 10 * * * ~/bin/cron-test >> /tmp/blah 2>>~/.cronlogs/$(basename $0) # $0 is "/bin/bash"
05 10 * * * ~/bin/cron-test >> /tmp/blah 2>>~/.cronlogs/$(basename $1) # $1 is empty?
06 10 * * * ~/bin/cron-test >> /tmp/blah 2>>~/.cronlogs/$(basename $2) # $2 is empty?






linux bash cron






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Feb 21 at 18:39









Jesse_b

13.7k23471




13.7k23471










asked Feb 21 at 18:23









reikredreikred

82




82







  • 1





    What is this being run from? What do you expect $0, $1, and $2 to be?

    – Jesse_b
    Feb 21 at 18:40






  • 1





    Better change your script ~/bin/cron-test to redirect its output. There you could use $0 to get the script name.

    – Bodo
    Feb 21 at 18:42











  • Jesse_b, it is supposed to be a cron job. Looking at $1 and $2 is an attempt to work around the fact that $0 does not have the desired value "~/bin/cron-test". I was hoping that $1 would be "-c" and $2 would be "~/bin/cron-test", for example.

    – reikred
    Feb 21 at 19:21












  • Bodo, I do not wish to hardcode output filenames into the script, I want to use stdout and stderr for testing and for non-cron use of the same scripts.

    – reikred
    Feb 21 at 19:23













  • 1





    What is this being run from? What do you expect $0, $1, and $2 to be?

    – Jesse_b
    Feb 21 at 18:40






  • 1





    Better change your script ~/bin/cron-test to redirect its output. There you could use $0 to get the script name.

    – Bodo
    Feb 21 at 18:42











  • Jesse_b, it is supposed to be a cron job. Looking at $1 and $2 is an attempt to work around the fact that $0 does not have the desired value "~/bin/cron-test". I was hoping that $1 would be "-c" and $2 would be "~/bin/cron-test", for example.

    – reikred
    Feb 21 at 19:21












  • Bodo, I do not wish to hardcode output filenames into the script, I want to use stdout and stderr for testing and for non-cron use of the same scripts.

    – reikred
    Feb 21 at 19:23








1




1





What is this being run from? What do you expect $0, $1, and $2 to be?

– Jesse_b
Feb 21 at 18:40





What is this being run from? What do you expect $0, $1, and $2 to be?

– Jesse_b
Feb 21 at 18:40




1




1





Better change your script ~/bin/cron-test to redirect its output. There you could use $0 to get the script name.

– Bodo
Feb 21 at 18:42





Better change your script ~/bin/cron-test to redirect its output. There you could use $0 to get the script name.

– Bodo
Feb 21 at 18:42













Jesse_b, it is supposed to be a cron job. Looking at $1 and $2 is an attempt to work around the fact that $0 does not have the desired value "~/bin/cron-test". I was hoping that $1 would be "-c" and $2 would be "~/bin/cron-test", for example.

– reikred
Feb 21 at 19:21






Jesse_b, it is supposed to be a cron job. Looking at $1 and $2 is an attempt to work around the fact that $0 does not have the desired value "~/bin/cron-test". I was hoping that $1 would be "-c" and $2 would be "~/bin/cron-test", for example.

– reikred
Feb 21 at 19:21














Bodo, I do not wish to hardcode output filenames into the script, I want to use stdout and stderr for testing and for non-cron use of the same scripts.

– reikred
Feb 21 at 19:23






Bodo, I do not wish to hardcode output filenames into the script, I want to use stdout and stderr for testing and for non-cron use of the same scripts.

– reikred
Feb 21 at 19:23











1 Answer
1






active

oldest

votes


















1














You could write a wrapper script to send the output to some particular place.



$ cat logwrap.sh
#!/bin/bash
logname=$(basename -- "$1").log
exec "$@" 2>> "~/.cronlogs/$logname"


Now, logwrap.sh id some command would run some command and send its output to /work/logs/some.log, so this would have its output sent to /work/logs/cron-test.log:



04 10 * * * /path/to/logwrap.sh ~/bin/cron-test 





share|improve this answer

























  • That's a good idea, for my particular purposes I would "exec 2> ~/.cronlogs/$logname";and let stdout pass through normally.

    – reikred
    Feb 21 at 21:25












  • I think the "$@" should be on the "exec" line, took the liberty to edit it.

    – reikred
    Feb 21 at 22:29











  • @reikred, yeah, it could be there, too, it seems to work. I don't think the difference matters much in this case. exec without a command sets the redirections for the rest of the script, so they're applied command that gets run by "$@". With exec "$@", the shell gets replaced by the command in $@, and again, of course the redirections apply to that since they're right there in the same command.

    – ilkkachu
    Feb 21 at 22:59












  • @reikred, The reason I had them separate was that originally, I had eval "$@" as the last command. Using eval would allow to pass a full shell command line to the script, with something like pipelines or such included. But it also invites extra quoting and your commands didn't need it anyway, so I left it out.

    – ilkkachu
    Feb 21 at 23:00










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
);



);













draft saved

draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f502150%2fsend-cron-output-to-a-filename-that-is-derived-from-the-program-name%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









1














You could write a wrapper script to send the output to some particular place.



$ cat logwrap.sh
#!/bin/bash
logname=$(basename -- "$1").log
exec "$@" 2>> "~/.cronlogs/$logname"


Now, logwrap.sh id some command would run some command and send its output to /work/logs/some.log, so this would have its output sent to /work/logs/cron-test.log:



04 10 * * * /path/to/logwrap.sh ~/bin/cron-test 





share|improve this answer

























  • That's a good idea, for my particular purposes I would "exec 2> ~/.cronlogs/$logname";and let stdout pass through normally.

    – reikred
    Feb 21 at 21:25












  • I think the "$@" should be on the "exec" line, took the liberty to edit it.

    – reikred
    Feb 21 at 22:29











  • @reikred, yeah, it could be there, too, it seems to work. I don't think the difference matters much in this case. exec without a command sets the redirections for the rest of the script, so they're applied command that gets run by "$@". With exec "$@", the shell gets replaced by the command in $@, and again, of course the redirections apply to that since they're right there in the same command.

    – ilkkachu
    Feb 21 at 22:59












  • @reikred, The reason I had them separate was that originally, I had eval "$@" as the last command. Using eval would allow to pass a full shell command line to the script, with something like pipelines or such included. But it also invites extra quoting and your commands didn't need it anyway, so I left it out.

    – ilkkachu
    Feb 21 at 23:00















1














You could write a wrapper script to send the output to some particular place.



$ cat logwrap.sh
#!/bin/bash
logname=$(basename -- "$1").log
exec "$@" 2>> "~/.cronlogs/$logname"


Now, logwrap.sh id some command would run some command and send its output to /work/logs/some.log, so this would have its output sent to /work/logs/cron-test.log:



04 10 * * * /path/to/logwrap.sh ~/bin/cron-test 





share|improve this answer

























  • That's a good idea, for my particular purposes I would "exec 2> ~/.cronlogs/$logname";and let stdout pass through normally.

    – reikred
    Feb 21 at 21:25












  • I think the "$@" should be on the "exec" line, took the liberty to edit it.

    – reikred
    Feb 21 at 22:29











  • @reikred, yeah, it could be there, too, it seems to work. I don't think the difference matters much in this case. exec without a command sets the redirections for the rest of the script, so they're applied command that gets run by "$@". With exec "$@", the shell gets replaced by the command in $@, and again, of course the redirections apply to that since they're right there in the same command.

    – ilkkachu
    Feb 21 at 22:59












  • @reikred, The reason I had them separate was that originally, I had eval "$@" as the last command. Using eval would allow to pass a full shell command line to the script, with something like pipelines or such included. But it also invites extra quoting and your commands didn't need it anyway, so I left it out.

    – ilkkachu
    Feb 21 at 23:00













1












1








1







You could write a wrapper script to send the output to some particular place.



$ cat logwrap.sh
#!/bin/bash
logname=$(basename -- "$1").log
exec "$@" 2>> "~/.cronlogs/$logname"


Now, logwrap.sh id some command would run some command and send its output to /work/logs/some.log, so this would have its output sent to /work/logs/cron-test.log:



04 10 * * * /path/to/logwrap.sh ~/bin/cron-test 





share|improve this answer















You could write a wrapper script to send the output to some particular place.



$ cat logwrap.sh
#!/bin/bash
logname=$(basename -- "$1").log
exec "$@" 2>> "~/.cronlogs/$logname"


Now, logwrap.sh id some command would run some command and send its output to /work/logs/some.log, so this would have its output sent to /work/logs/cron-test.log:



04 10 * * * /path/to/logwrap.sh ~/bin/cron-test 






share|improve this answer














share|improve this answer



share|improve this answer








edited Feb 21 at 22:51









reikred

82




82










answered Feb 21 at 19:39









ilkkachuilkkachu

61.6k10101177




61.6k10101177












  • That's a good idea, for my particular purposes I would "exec 2> ~/.cronlogs/$logname";and let stdout pass through normally.

    – reikred
    Feb 21 at 21:25












  • I think the "$@" should be on the "exec" line, took the liberty to edit it.

    – reikred
    Feb 21 at 22:29











  • @reikred, yeah, it could be there, too, it seems to work. I don't think the difference matters much in this case. exec without a command sets the redirections for the rest of the script, so they're applied command that gets run by "$@". With exec "$@", the shell gets replaced by the command in $@, and again, of course the redirections apply to that since they're right there in the same command.

    – ilkkachu
    Feb 21 at 22:59












  • @reikred, The reason I had them separate was that originally, I had eval "$@" as the last command. Using eval would allow to pass a full shell command line to the script, with something like pipelines or such included. But it also invites extra quoting and your commands didn't need it anyway, so I left it out.

    – ilkkachu
    Feb 21 at 23:00

















  • That's a good idea, for my particular purposes I would "exec 2> ~/.cronlogs/$logname";and let stdout pass through normally.

    – reikred
    Feb 21 at 21:25












  • I think the "$@" should be on the "exec" line, took the liberty to edit it.

    – reikred
    Feb 21 at 22:29











  • @reikred, yeah, it could be there, too, it seems to work. I don't think the difference matters much in this case. exec without a command sets the redirections for the rest of the script, so they're applied command that gets run by "$@". With exec "$@", the shell gets replaced by the command in $@, and again, of course the redirections apply to that since they're right there in the same command.

    – ilkkachu
    Feb 21 at 22:59












  • @reikred, The reason I had them separate was that originally, I had eval "$@" as the last command. Using eval would allow to pass a full shell command line to the script, with something like pipelines or such included. But it also invites extra quoting and your commands didn't need it anyway, so I left it out.

    – ilkkachu
    Feb 21 at 23:00
















That's a good idea, for my particular purposes I would "exec 2> ~/.cronlogs/$logname";and let stdout pass through normally.

– reikred
Feb 21 at 21:25






That's a good idea, for my particular purposes I would "exec 2> ~/.cronlogs/$logname";and let stdout pass through normally.

– reikred
Feb 21 at 21:25














I think the "$@" should be on the "exec" line, took the liberty to edit it.

– reikred
Feb 21 at 22:29





I think the "$@" should be on the "exec" line, took the liberty to edit it.

– reikred
Feb 21 at 22:29













@reikred, yeah, it could be there, too, it seems to work. I don't think the difference matters much in this case. exec without a command sets the redirections for the rest of the script, so they're applied command that gets run by "$@". With exec "$@", the shell gets replaced by the command in $@, and again, of course the redirections apply to that since they're right there in the same command.

– ilkkachu
Feb 21 at 22:59






@reikred, yeah, it could be there, too, it seems to work. I don't think the difference matters much in this case. exec without a command sets the redirections for the rest of the script, so they're applied command that gets run by "$@". With exec "$@", the shell gets replaced by the command in $@, and again, of course the redirections apply to that since they're right there in the same command.

– ilkkachu
Feb 21 at 22:59














@reikred, The reason I had them separate was that originally, I had eval "$@" as the last command. Using eval would allow to pass a full shell command line to the script, with something like pipelines or such included. But it also invites extra quoting and your commands didn't need it anyway, so I left it out.

– ilkkachu
Feb 21 at 23:00





@reikred, The reason I had them separate was that originally, I had eval "$@" as the last command. Using eval would allow to pass a full shell command line to the script, with something like pipelines or such included. But it also invites extra quoting and your commands didn't need it anyway, so I left it out.

– ilkkachu
Feb 21 at 23:00

















draft saved

draft discarded
















































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.




draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f502150%2fsend-cron-output-to-a-filename-that-is-derived-from-the-program-name%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown






Popular posts from this blog

How to check contact read email or not when send email to Individual?

Bahrain

Postfix configuration issue with fips on centos 7; mailgun relay