Re: crontab question

[scottstef]

in reply to crontab question

Try creating an error log for your crontab entry and sending your error messages to it:
0 23 * * * /my_path/my_script.pl >> /my_path/errordir/script_errors.txt
Then you can read the error log for any error messages

"The social dynamics of the net are a direct consequence of the fact that nobody has yet developed a Remote Strangulation Protocol." -- Larry Wall

[Anonymous Monk]

doesn't that append STDOUT /my_path/errordir/script_errors.txt?

I thought to redirect STDERR in "modern" shells you had to do something like .... &2>/errola.txt where &1 is STDOUT &2 is STDERR and &3 is like a temporary redirection handle (just like &4), so that you can swap "streams"

[nardo]

That would be 2>/errola.txt rather than &2>/errola.txt, the & is used when redirecting one file descriptor to another: 2>&1 redirects stderr to stdout. The easiest way to remember where the & goes is that: &2>1 could either redirect to filedescriptor 1 or to a file named '1' and a file named '1' isn't that unusual a name while 2>&1 is either going to redirect to filedescriptor 1 or a file named '&1' and it's unlikely that someone will want a file named '&1' so that is the way to do it. If you ever want to redirect to a file named '&1' you could: 2>'&1' but I can't think of a situation where you would ever want a file named &1, but then again I can't think of a situation where someone would want an album by N*Sync and I was totally wrong there.

[converter]

If you write to stderr the output will be emailed to the user named in the MAILTO environment variable, or to the crontab owner (unless MAILTO is defined as an empty string), but this may vary with implementation. That's probably easier than keeping a separate log file.