In the UNIX world execute permission on a directory means that you can CD into it; with it removed the directory cannot be accessed (i.e. you can't get a list of the files in the directory)
Strictly speaking, you can get a list of files in the directory. i.e., opendir() and readdir() will not return "Permission denied". However, you can't access any of the files within the directory.
BTW, sounds like something you'd see in an Adobe installer.
Strictly speaking, you can get a list of files in the directory. i.e., opendir() and readdir() will not return "Permission denied". However, you can't access any of the files within the directory.
Yes, and this is commonly used for the parent directory of a publically readable directory.
Fore example, you can't read or write anything in my home directory but you can execute through it to read stuff form my public_www directory.
If the execute bit form my home is removed, that breaks my webpage.
I was expecting a bug that had some subtle relation to the Javascript language... this example would apply to any language and is essentially demonstrating a strong lack of knowledge and/or carelessness with file permission masks / chmod and unix filesystems generally.
I guess these just don't match my personal definition of a software bug... I was expecting an unexpected result as a product of good programming. This is just "5 reasons this line of javascript shouldn't have been written" and seems to be more about UNIX permissions than code.
I don't know anyone who defines a "bug" as "an unexpected result as a product of good programming." Bugs are when code is wrong: when it doesn't do what it says, when it doesn't do what was asked of it, when it doesn't do what the user reasonably expects. Bugs are not the result of good programming.
I disagree. I would say there is a distinction between an error and a bug. There's certainly some grey area there, but, for example, if my code sets permissions for a directory instead of a file, I made an error. If my code sets permissions for a file, but produces unexpected results in certain cases because of an implementation detail, then that's a bug.
A bug is code that doesn't behave as the author intended it to. It doesn't matter if the bug is due to some subtle interaction in the language, or just plain bone-headedness on the part of the programmer.
Is it at all possible for there to be 5 distinct and unexpected results caused by a single, well-written line of code? You're right that these aren't subtle bugs affecting a large piece of software, but why would you expect that given the title?
I'd really like to point fingers and scold, but other than the octal/decimal bug I feel like I've been in enough product-manager-screaming-for-a-fix positions to understand how code like that can make it into a production environment.
Really this should be posted on wherever _those_ guys hang out than hacker news, where we're unlikely to write code like that (even under duress)
1. Setting the permission on the wrong thing (directory instead of file)
2. Setting the permissions to 666 instead of 0666.
A design "bug" is only a bug if it was unintentional. The other two "bugs" are pedantry that you'd only expect out of a compiler that spits out tons of cascading "errors" resulting from a single actual error.
Strictly speaking, you can get a list of files in the directory. i.e., opendir() and readdir() will not return "Permission denied". However, you can't access any of the files within the directory.
BTW, sounds like something you'd see in an Adobe installer.