Many programs do not handle non-blocking stdio very well. In particular,
man and less have serious problems with this, and since stdout isn't being
flushed after each write, the output jumps about on the screen as you page
down. Programs that do use non-blocking stdio will set that flag themselves
(as node does).
This puts the stdio file descriptors into blocking mode before sharing them
with the child process, so that one could spawn a vim subprocess, or some
other program that depends on blocking IO.
Any path.join or path.normalize that starts with a / will not go "above" that after normalization. This is important because /../foo is almost *always* some sort of error, and doesn't match the corollary in sh: `cd $p; pwd`
At the worse, this can be a vector for exploits, since a static file server might do path.join(docroot, path.normalize("/"+req)) to get the file. If the normalized request path could be something like "/../../../etc/passwd" then bad things could happen.
Before there was this comment:
Can't strip trailing slashes since module.js incorrectly
thinks dirname('/a/b/') should yield '/a/b' instead of '/a'.
But now, such thinking is corrected.
- Buffer.toString('ascii', 0, 0) incorrectly returns the entire contents
of the buffer. Fix this.
- Provide similar behavior to Buffer.write() and Buffer.copy() when
dealing with 0-length in valid and invalid byte ranges.
This is ever so slightly less efficient than caching based on ID, since the
filename has to be looked up before we can check the cache. However, it's
the most minimal approach possible to get this change in place. Since
require() is a blocking startup-time operation anyway, a bit of slowness is
not a huge problem.
A test involving require.paths modification and absolute loading. Here's the
gist of it.
Files: /p1/foo.js /p2/foo.js
1. Add "/p1" to require.paths.
2. foo1 = require("foo")
3. assert foo1 === require("/p1/foo") (fail)
4. Remove /p1 from require.paths.
5. Add /p2 to require.paths.
6. foo2 = require("foo")
7. assert foo1 !== foo2 (fail)
8. assert foo2 === require("/p2/foo") (fail)
It's an edge case, but it affects how dependencies are mapped by npm.
If your module requires foo-1.2.3, and my module requires foo-2.3.4,
then you should expect to have require("foo") give you foo-1.2.3, and
I should expect require("foo") to give me foo-2.3.4. However, with
module ID based caching, if your code loads *first*, then your "foo"
is THE "foo", so I'll get your version instead of mine.
It hasn't yet been a problem, but only because there are so few
modules, and everyone pretty much uses the latest version all the
time. But as things start to get to the 1.x and 2.x versions, it'll
be an issue, I'm sure. Dependency hell isn't fun, so this is a way to
avoid it before it strikes.