Live data from Hacker News

Cronic - A cure for Cron's chronic email problem

habilis.net

1–10 of 47 posts

Re: Cronic - A cure for Cron's chronic email problem

#2
That's not too bad and too be honest I think I'd like to see it inside cron. So we'd just..

* * * * * blahscript.sh

and it'd do what cronic does without any extra. I know i know the "one tool one job", but i believe this job is really cron's job (word play unintended)

Re: Cronic - A cure for Cron's chronic email problem

#5
In a dozen or so years of administrating many different Unix machines, I've never had cron email be a problem and I get a few (useful) emails from various cron scripts every day.

This interacts badly with many unix commands, which often send status info to standard out. Some commands have a quiet options, but that can turn off all error output too.

Maybe it's that I've mostly been administrating BSD machines, and so most of the tools follow old Unix guidelines like not printing anything unless it's necessary, echoing errors to stderr, using proper exit statuses, etc. (http://fmg-www.cs.ucla.edu/geoff/interfaces.html) I think it's a GNUism/Linuxism that commands are overly chatty, writing junk all over stdout (like author/license information - do we need to see this every single time?), and using ANSI colors by default.

Re: Cronic - A cure for Cron's chronic email problem

#6
post #5

In a dozen or so years of administrating many different Unix machines, I've never had cron email be a problem and I get a few (useful) emails from various cron scripts every day. This interacts badly with many unix commands, which often send status info to standard out. Some commands have a quiet options, but that can turn off all error output too. Maybe it's that I've mostly been administrating BSD machines, and so…

Which tools are you talking about? The standard software suite is basically identical between the systems. And what differences there are lie in the implementations of the core stuff, whose behavior is specified by POSIX for the most part.

I'm sure there are exceptions somewhere. But in something you'd throw into a cron job? Frankly, that seems like a very weird snipe.

Re: Cronic - A cure for Cron's chronic email problem

#7
post #6
post #5

In a dozen or so years of administrating many different Unix machines, I've never had cron email be a problem and I get a few (useful) emails from various cron scripts every day. This interacts badly with many unix commands, which often send status info to standard out. Some commands have a quiet options, but that can turn off all error output too. Maybe it's that I've mostly been administrating BSD machines, and so…

Which tools are you talking about? The standard software suite is basically identical between the systems. And what differences there are lie in the implementations of the core stuff, whose behavior is specified by POSIX for the most part. I'm sure there are exceptions somewhere. But in something you'd throw into a cron job? Frankly, that seems like a very weird snipe.

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.

Re: Cronic - A cure for Cron's chronic email problem

#8
I 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

Re: Cronic - A cure for Cron's chronic email problem

#9
post #3

I added a simplified version of chronic to moreutils a while back. http://joeyh.name/code/moreutils (also packaged in some major linux distros)

It's not just simplified, but more secure. Your version doesn't write to predictable filenames in /tmp like the original does.

Re: Cronic - A cure for Cron's chronic email problem

#10
post #6

Earlier quoted context omitted.

Which tools are you talking about? The standard software suite is basically identical between the systems. And what differences there are lie in the implementations of the core stuff, whose behavior is specified by POSIX for the most part. I'm sure there are exceptions somewhere. But in something you'd throw into a cron job? Frankly, that seems like a very weird snipe.

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.
Post reply on HN