[deleted]
Cronic - A cure for Cron's chronic email problem
41–47 of 47 posts
Re: Cronic - A cure for Cron's chronic email problem
#42Earlier quoted context omitted.
I'm guessing ls which colors; perhaps keychain (very colorful output). I see less of the license stuff these days but no doubt there's a few around.
On Red Hat based systems, ls is an alias for ls --color=auto which means that colors are used only on terminals, not pipes or files.
And no one should ever be using ls in a shell script anyway. Shell globbing and find are the proper tools.
Re: Cronic - A cure for Cron's chronic email problem
#43I use a wrapper similar to this. Sometimes you just need to call a script someone else wrote that you have no control over the output. I never want an email unless the script results in a non-zero rc.
Re: Cronic - A cure for Cron's chronic email problem
#44Since this is hackernews, can someone explain the rational behind putting the 2>&1 after the > ? I know it works, but this reads to me: command > file.txt 2>&1 "write the output of command to file.txt and then map the error output to stdout" It makes so much more sense to write: command 2>&1 > file.txt There is clearly something in my brain that is confused about how redirection works.
Siblings have already responded to this well, so I'll just add an example: $ ls x ls: cannot access x: No such file or directory $ ls x >/dev/null 2>&1 $ ls x 2>&1 >/dev/null ls: cannot access x: No such file or directory The first command shows us trying to list a non-existent file, raising an error. The second sends stderr to stdout before sending stdout to null, suppressing all output. The third sends the error to…
can you come up with a way to verify this?
perl -E 'say q{STDOUT!}; say {*STDERR} q{STDERR!}'
Re: Cronic - A cure for Cron's chronic email problem
#45I have this problem, I only want to be emailed upon failure. However, the crontab of the account is shared by several different jobs run by different people, and I don't have control over that. Perhaps I could set the email in the crontab line? * * * * * MAILTO=me@example.com blahscript.sh
You can set MAILTO by itself between the job lines in the crontab; e.g.: MAILTO=user1@example.com * */10 * * * script1 5 * * * * script2 MAILTO=user2@example.com * * * * * script3 Any output from script1 and 2 will be sent to user1 and any from script3 to user2.
Not all cron daemons. Vixie cron can do this, but Dillon's cron, which is a lightweight cron daemon with extra features, can't.
Re: Cronic - A cure for Cron's chronic email problem
#46Earlier quoted context omitted.
You can set MAILTO by itself between the job lines in the crontab; e.g.: MAILTO=user1@example.com * */10 * * * script1 5 * * * * script2 MAILTO=user2@example.com * * * * * script3 Any output from script1 and 2 will be sent to user1 and any from script3 to user2.
Not all cron daemons. Vixie cron can do this, but Dillon's cron, which is a lightweight cron daemon with extra features, can't.
Thanks for the clarification.
Re: Cronic - A cure for Cron's chronic email problem
#47Earlier quoted context omitted.
I think it's an OSX-ism. Most OSX devs I've seen treat their command-line utilities like their GUI utilities, with nice looking albeit chatty output. These utilities then get released into the Linux world, where they often work without any modification.
Or it's just younger devs, who like to see something when they run their program.
Yes, exactly this. I know I'm guilty of wanting to see something cool happen. :)