Frustrating Unix pitfall of the day: esoteric cron rules
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).
>This isn't a Unix pitfall, it's a Debian pitfall.
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.
"It might break existing code" is usually a winning argument. It takes a very strong opposing argument to beat it. If you don't believe in this, I don't want to use any of your code.
I can see how server software needs to be more conservative about making changes. I'm glad I am not using server software anymore for my personal software environment.
Slackware. As usual, takes the good bits out of both RedHat's and Debian's run-parts. It allows .{whatever} but ignores obvious, well-known suffixes like .bak etc.
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
Thank you for that clarification. I've been running shell scripts named .sh all the time without trouble. Of course, I run them from crontab. I'd never even heard of this /etc/cron.* thing.
That's what Krafft says in _The Debian System_, actually - that it would be a real mess if new packages all had to edit the same crontab to install and deinstall themselves, but a directory-based system was very clean.
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).
At the end of the report, you can see they added the --regex flag to allow for user-defined filename validation.
A few days debugging? How could this possibly take any more than 5 minutes to work out on your own? If it takes a few days then maybe you are in the wrong job.
Asked there, but I'll tack it on here too: What is the purpose of that absurd-seeming restriction on file names? If you can drop arbitrary executables into directories on the file system, you've already "won", so I assume it's not security. I've read the run-parts man page, and that just pushes the problem back one level. If it's just to avoid running old files, that's an absurdly large hammer to hit that problem with.
Wait, my intented question was, `do those backup files have the executable permission bits set'? Not `do they hold valid input for interpreter/CPU'.
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
which makes it trivial to enable/disable various services by simply chmod +x SOME_FILE / chmod -x SOME_FILE. If EMACS' backup files were marked as not executable by the editor, that would be `case closed' for me, no need to pay extra attention to characters in file names.
Yes, it's not a bug in Vixie Cron (which I think BSD cron may use) but in the Linux distros (who are responsible for adding run-parts).
.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.
I think I'm missing something. The comments that appear as if they should contain the answers contain nothing. Have the answers been removed? Does Reddit's [spoiler] tag do fun javascript-y things that don't work on IE8? Or am I so obtuse and unobservant that I'm missing something obvious?
That was the first thing I tried, to no avail. I was able to see his response by going to his profile and hovering over the word "spoiler" in his comment stream. The word "spoiler" doesn't appear for me in the threaded comments and clicking through the word "spoiler" results in a 404.
That has to do with how spoiler tags are set up on that subreddit: the actual spoiler content is in the title attribute of the link and the href points to /s. The CSS for the subreddit uses an attribute selector to find links pointing to /s and styles them appropriately.
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.
Another fun one is that if your file doesn't end in a newline, cron will silently ignore the last line! Lost a couple days of production data at my last job due to that "feature".
Since everyone should hopefully know /etc/cron* is a nonstandard cron directory, and an addon from Debian, it would be hopeful that you would also have discovered the relevant documentation as why this is, ie run-parts(8), like mentioned.
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've been using Jenkins to do every single thing I used to do in cron these days. Lots easier to visualize execution, and catch potential errors. More overhead, yes. Saved me tons of time, yes.
Tap the text and it will become visible, then it navigates to reddit.com/s (no idea why). Then click back and the text will still be readable (just confirmed on my iPhone 4)
Been there done that. It's very annoying indeed. I wish things were slightly less finicky in *NIX platforms as a rule. They need a serious de-crufting session (plan 9 looks very much less crufty).
The lack of errors was annoying and counterintuitive. I like the usual UNIX mantra of blow up noisily if an assumption is made but it just doesn't happen there.
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).