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.
