4 ms·

Motherfriggin' Cron

PeterWhittaker 12y ago
You used a partial path in cron? Wha...? 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.
- bediger4000 12y ago
  I understand your viewpoint, but unless those whippeer snappers make the mistakes, they'll never learn.
  - alex_doom 12y ago
    But without grumpy elders, we'll never know we fuck up! Chicken > Egg < Chicken?
- notduncansmith 12y ago
  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!
- PeterWhittaker 12y ago
  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
- PeterWhittaker 12y ago
  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.
__DarkBlue 12y ago
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".
thaumaturgy 12y ago
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.

You used a partial path in cron? Wha...? 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.

bediger4000 12y ago
I understand your viewpoint, but unless those whippeer snappers make the mistakes, they'll never learn.
- alex_doom 12y ago
  But without grumpy elders, we'll never know we fuck up! Chicken > Egg < Chicken?
notduncansmith 12y ago
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!
PeterWhittaker 12y ago
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
PeterWhittaker 12y ago
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.

__DarkBlue 12y ago

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".

thaumaturgy 12y ago

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.