4 ms·

I wonder how many files with a name containing \n are in the wild. And if you encounter such a file, does it really matter if you accidentally delete it? Waist

by slice 17y ago

I wonder how many files with a name containing \n are in the wild. And if you encounter such a file, does it really matter if you accidentally delete it? Waisting brain cycles to save CPU cycles (in the wrong places) is shameful, insulting and boring. It would be amazing if there weren't tons of other, much more significant, things that deserved attention in the relevant script, system, or the developer's life. (sign)

duskwuff 17y ago
I've seen some concepts thrown around about a (Linux) kernel patch to disallow filenames which contain unprintable characters. I approve of them. With regard to why this matters, it's not uncommon for badly written scripts to interpolate filenames directly into commands. Consider this Perl fragment: $sessionFiles = `ls /tmp/session_*`; system("rm -f $sessionFiles"); and what it would do with a file called: "/tmp/session_blah; chmod +s"
omouse 17y ago
And if you encounter such a file, does it really matter if you accidentally delete it? It matters. Leaving a bug around is disgusting and wasteful especially when you can fix it. * would be amazing if there weren't tons of other, much more significant, things that deserved attention in the relevant script, system, or the developer's life. (sign)* Fixing bugs and writing programs that have as few bugs as possible is very important.
- slice 17y ago
  When you find a bug, by all means, go ahead and fix it. (Well, not always. You need to make sure your fix is not likely to introduce a more severe bug. Not all bugs made equal and some guts-feeling required). If your goal is to make your system as robust as engineerically possible, you should most likely pay more attention in some directions and less in other. It's not only about quantity - you better have no critical bugs then have only-a-very-few critical ones.
prodigal_erik 17y ago
The problem is the file you accidentally delete (or whatever) is probably not the one with the weird name. Most bogus filenames I've seen were created by shell scripts that had a set of commands that was accidentally quoted instead of executed, so they tend to contain the names of files which were important to the author.

by slice 17y ago

duskwuff 17y ago

I've seen some concepts thrown around about a (Linux) kernel patch to disallow filenames which contain unprintable characters. I approve of them. With regard to why this matters, it's not uncommon for badly written scripts to interpolate filenames directly into commands. Consider this Perl fragment: $sessionFiles = `ls /tmp/session_*`; system("rm -f $sessionFiles"); and what it would do with a file called: "/tmp/session_blah; chmod +s"

omouse 17y ago

And if you encounter such a file, does it really matter if you accidentally delete it? It matters. Leaving a bug around is disgusting and wasteful especially when you can fix it. * would be amazing if there weren't tons of other, much more significant, things that deserved attention in the relevant script, system, or the developer's life. (sign)* Fixing bugs and writing programs that have as few bugs as possible is very important.

slice 17y ago
When you find a bug, by all means, go ahead and fix it. (Well, not always. You need to make sure your fix is not likely to introduce a more severe bug. Not all bugs made equal and some guts-feeling required). If your goal is to make your system as robust as engineerically possible, you should most likely pay more attention in some directions and less in other. It's not only about quantity - you better have no critical bugs then have only-a-very-few critical ones.

prodigal_erik 17y ago

The problem is the file you accidentally delete (or whatever) is probably not the one with the weird name. Most bogus filenames I've seen were created by shell scripts that had a set of commands that was accidentally quoted instead of executed, so they tend to contain the names of files which were important to the author.