A cron pitfall that will probably snare you at least once in your career
reddit.com
reddit.com
This isn't a Unix pitfall, it's a Debian pitfall. Further, it's not inherent to cron, but to the /etc/cron.{hourly,daily,weekly,monthly} concept as implemented by Debian.
Scripts in these directories are run via /usr/bin/run-parts, which is invoked via /etc/crontab. It is Debian's run-parts that imposes the naming restriction. Red Hat's run-parts doesn't have this restriction (go take a look, it's a shell script).
And that is an example of why I do not run Debian any more: (1) it assumes that I have nothing better to do than learn all of the details of the Debian system and (2) as soon as some complication like this dots-in-filenames thing makes it into stable, it is very difficult to remove because most Debian maintainers consider it-might-break-existing-code a winning argument.
From man run-parts: run-parts automatically skips files with certain suffixes that are generally associated with backup or extra files. Any file that ends in one of these will be silently ignored: ~ ^ , .bak .new .rpmsave, .rpmorig .rpmnew .swp
I can understand not changing the behaviour wrt historical
precedent: I have been told that people used to rely on the
ignore-dot mechanism to disable things (e.g. mv foo foo.disabled).
Look at the bright side: this is a few days of debugging and difficult to explain to the people signing your check. Aren't you glad it's there now?
(honestly I dunno; have never used EMACS yet)
Then again, if you're editing files in /etc/ as root and using emacs to do so, you kinda deserve what you get.
In Slackware's startup scripts, there's a good bunch of
if [ -x SOME_FILE ]; then # if the file is executable, run it
./SOME_FILE start
fi
They are in fact created by renaming the real file to the backup name, then saving the real file and copying the permissions.
.py, .pl, .sh and (as people realize they'are actually writing bash scripts) .bash are standards people actually use. Having them break in what amounts to an include dir is bad mojo.
Is the implication that you can have .dpkg files in cron folders that you wouldn't want to try to execute?
https://bugs.launchpad.net/ubuntu/+source/debianutils/+bug/3... http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=68561
I'm just hoping I'm not color-blind :-P
Very strange.
If you view the posts outside of the context of the subreddit, there's no special CSS, so the link appears normally with some title text that appears on hover.
I can't remember if it refuses to parse the file or ignores the last line, but it's not a fun thing to bump against.
The manpage states you can pass --test <dir> and it will show you all the scripts it would have run. This should have been something done before any assumption was made as to this working off the bat.
On my systems now, or old Solaris machines I used to admin, I would always do an "at now <script>" to make sure there were not any $PATH issues before putting the script in production. I've always tested to make sure the generic skeleton of the script would work before assuming anything...
I thought I was doing well when I finally learned to remember the "no cron files that don't include an empty newline" rule.
In addition to that, the restriction is silly and utterly pointless.
I have plenty of scripts and php and such running in crons all over the place.
It is formatted like this (IIRC):
[spoiler](/s"More goes here")
I eventually just added it to the crontab of a user and that was that, but I'm so glad to finally know WHY.
This is such an arcane restriction and its really hard to debug since there are no errors anywhere.