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.
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.
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.
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.
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).
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.
>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.
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
"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.
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)
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...
69 comments
[ 5.2 ms ] story [ 119 ms ] thread(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
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.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 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.
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.
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?
I have plenty of scripts and php and such running in crons all over the place.
In addition to that, the restriction is silly and utterly pointless.
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 thought I was doing well when I finally learned to remember the "no cron files that don't include an empty newline" rule.
It is formatted like this (IIRC):
then in CSS there is a match for url[href=/s] that provides the onmouseover stuff.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...