os x 10.5 cron == FAIL
Apple is a UNIX right? So it has cron.
Well, sort of. They've witten their own terrible replacement, and the support for "legacy", ie. UNIX cron is busted out of the box.
It seems that when vixie cron launches an external editor for crontab -e it
1 - holds the file open, assuming all editors will always rewrite the same file, not ever create a new file.
In addition:
2 - the default editor on unix systems is vi
3 - the default vi on OS X is vim
4 - vim does not not edit files in place, but creates a new file as part of its backup pattern (write -> fsync -> rename), which is much smarter
Thus, crontab -e just produces an unhelpful message "temp file must be edited
in place" and the changes made are discarded.
So, crontab -e on OS X is broken out of the box, and could never have worked
in the simplest possible test.
Go apple quality engineering.
But why does this all work fine on Linux?
Well, vim is aware of this, and works around it. When vim edits files in /tmp
or /var/tmp, it assumes you probably didn't need backups of temporary files.
In fact backups of temporary files can be a nuisance. So it puts /tmp and
/var/tmp into a variable which describes directories in which not to apply the
backup strategy.
Thus crontab -e always works on Linux, Solaris, HP-UX, etc, etc with vim out
of the box.
So why *doesn't* this work on OS X?
OS X has /tmp as a symbolic link to /private/tmp for its own inscrutable
reasons. Thus, vim sees that the edits are happening in /private/tmp, which
is not on the list, so the exception does not apply, and the normal backup
strategy is used, so that crontab -e does not work.
So OS X could fix this by either:
- adding /private/tmp to the vim no-backup list in /etc/vimrc
OR
- make /tmp a normal directory, not a symbolic link (why is it anyway?)
I mean, Apple has only had about a year to notice a trivial-to-fix bug in their configuration. I guess 6 updates isn't enough to get you to UNIX compliance.
Well, sort of. They've witten their own terrible replacement, and the support for "legacy", ie. UNIX cron is busted out of the box.
It seems that when vixie cron launches an external editor for crontab -e it
1 - holds the file open, assuming all editors will always rewrite the same file, not ever create a new file.
In addition:
2 - the default editor on unix systems is vi
3 - the default vi on OS X is vim
4 - vim does not not edit files in place, but creates a new file as part of its backup pattern (write -> fsync -> rename), which is much smarter
Thus, crontab -e just produces an unhelpful message "temp file must be edited
in place" and the changes made are discarded.
So, crontab -e on OS X is broken out of the box, and could never have worked
in the simplest possible test.
Go apple quality engineering.
But why does this all work fine on Linux?
Well, vim is aware of this, and works around it. When vim edits files in /tmp
or /var/tmp, it assumes you probably didn't need backups of temporary files.
In fact backups of temporary files can be a nuisance. So it puts /tmp and
/var/tmp into a variable which describes directories in which not to apply the
backup strategy.
Thus crontab -e always works on Linux, Solaris, HP-UX, etc, etc with vim out
of the box.
So why *doesn't* this work on OS X?
OS X has /tmp as a symbolic link to /private/tmp for its own inscrutable
reasons. Thus, vim sees that the edits are happening in /private/tmp, which
is not on the list, so the exception does not apply, and the normal backup
strategy is used, so that crontab -e does not work.
So OS X could fix this by either:
- adding /private/tmp to the vim no-backup list in /etc/vimrc
OR
- make /tmp a normal directory, not a symbolic link (why is it anyway?)
I mean, Apple has only had about a year to notice a trivial-to-fix bug in their configuration. I guess 6 updates isn't enough to get you to UNIX compliance.