Motherfriggin' Cron(duncanmsmith.com)
duncanmsmith.com
Motherfriggin' Cron
http://duncanmsmith.com/blog/motherfriggin-cron/
3 comments
Well, I've never had someone looking over my shoulder to tell me I was doing it wrong :)
As for using partial paths, I was using something that I expected to be in the $PATH, and had no real reason to believe that it wouldn't be there. I definitely learned my lesson with that one.
Thanks for the tip!
As for using partial paths, I was using something that I expected to be in the $PATH, and had no real reason to believe that it wouldn't be there. I definitely learned my lesson with that one.
Thanks for the tip!
Well, poop. I keep forgetting that HN likes to join lines.
% crontab -l > file
% vi file
% crontab < file
is what that should have looked like.
#oldman #therewasnomarkupbackthen #mylawnisdead
% crontab -l > file
% vi file
% crontab < file
is what that should have looked like.
#oldman #therewasnomarkupbackthen #mylawnisdead
I understand your viewpoint, but unless those whippeer snappers make the mistakes, they'll never learn.
But without grumpy elders, we'll never know we fuck up! Chicken > Egg < Chicken?
And while we're at it: Always make sure your crontab-to-be file ends with an empty line. I tripped over that many, many times before it burned itself into my brain.
This is all pretty standard stuff for cron. Which isn't to say that it couldn't be better, but I think the main problem here is expecting it to work like other parts of OS X.
With OS X specifically, launchd is trying to replace cron and you might be better off just using that. You can still create a cron job and get it to run and all that, but OS X is doing it with launchd and Apple has a tendency to pull the rug out from under people when it's convenient for them.
Cron will send both errors and program output to your local mail daemon. Pretty much all BSD/Linux/etc. systems have local mail delivery configured to drop stuff into /var/mail/[login username], to be read by the "mail" (or similar) commands on the commandline. If you don't want that, you have to set up a mail daemon and configure it to forward mail to your regular account using your ISP. OS X might have sendmail built in, which can do this (although sendmail configuration isn't very fun), or postfix should work too.
If email is too much of a hassle, you can use the >> operator at the end of your command to direct output to a file: [command] >> /path/to/file
And, yeah, cron runs in its own environment, so it won't have access to your PATH or other variables.
With OS X specifically, launchd is trying to replace cron and you might be better off just using that. You can still create a cron job and get it to run and all that, but OS X is doing it with launchd and Apple has a tendency to pull the rug out from under people when it's convenient for them.
Cron will send both errors and program output to your local mail daemon. Pretty much all BSD/Linux/etc. systems have local mail delivery configured to drop stuff into /var/mail/[login username], to be read by the "mail" (or similar) commands on the commandline. If you don't want that, you have to set up a mail daemon and configure it to forward mail to your regular account using your ISP. OS X might have sendmail built in, which can do this (although sendmail configuration isn't very fun), or postfix should work too.
If email is too much of a hassle, you can use the >> operator at the end of your command to direct output to a file: [command] >> /path/to/file
And, yeah, cron runs in its own environment, so it won't have access to your PATH or other variables.
It's great that you managed to get cron working the way you wanted. However, I'm curious, why not just put your Vim settings on Dropbox or something like BitTorrentSync - then alias your local settings/configs on each machine to the corresponding file/folder in your Dropbox?
I use this method for all settings and configs that I wish to share across multiple machines. Personally I find it more manageable than any other solution, and certainly less convoluted than "multiple rounds of ssh duncan@some-server... git pull origin master".
I use this method for all settings and configs that I wish to share across multiple machines. Personally I find it more manageable than any other solution, and certainly less convoluted than "multiple rounds of ssh duncan@some-server... git pull origin master".
Always, always use fully qualified filenames in cron, never rely on environment variables, ever.
And what are you doing editing your crontab directly?
% crontab -l > file % vi file % crontab < file
That's the proper incantation. Let the tool do what it is supposed to do.
Whipper snappers.