Check cwd before spawning child process

[jhnns]

• Version: v7.6.0
• Platform: Darwin Pecorino.local 16.4.0 Darwin Kernel Version 16.4.0: Thu Dec 22 22:53:21 PST 2016; root:xnu-3789.41.3~3/RELEASE_X86_64 x86_64

When a cwd is passed to child_process.spawn() that does not exist, node just reports ENOENT:

const spawn = require("child_process").spawn

spawn(process.execPath, { cwd: "/does/not/exist" });

> Error: spawn /usr/local/bin/node ENOENT
    at exports._errnoException (util.js:1028:11)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:193:32)
    at onErrorNT (internal/child_process.js:359:16)
    at _combinedTickCallback (internal/process/next_tick.js:74:11)
    at process._tickDomainCallback (internal/process/next_tick.js:122:9)

This error message is very confusing because it reads like /usr/local/bin/node does not exist. It took me several hours to debug this issue, including serious doubts in my sanity 😁.

Do you think it is feasible to check the cwd before spawning the process, or is there a use-case/is it possible to spawn a process with a non-existent cwd? If it's not feasible, would it be an option to include the cwd in the error message to give a slight hint in the right direction?

[bnoordhuis]

That's going to be difficult because the error needs to bubble up from a long way down. I don't think it can be done without backwards-incompatible changes to libuv, which means it won't happen before libuv v2.0.

[jhnns]

That's going to be difficult because the error needs to bubble up from a long way down

This means that checking the cwd beforehand (with fs.exists for instance) is not an option?

[bnoordhuis]

No, that's prone to race conditions (TOCTOU issues.) It's going to work alright 99% of the time and that might be acceptable for an npm module but requirements for node.js core are more stringent.

[XadillaX]

How about add an option checkCWD?

something like:

.spawn(path, { cwd: "some/cwd", checkCWD: true });

[bnoordhuis]

Check-before-use is an anti-pattern. It's not something to codify in the API.

[bnoordhuis]

@mrpeu Probably because you use ~ in the file path. No shell expansion is done.

[gibfahn]

Check-before-use is an anti-pattern.

@bnoordhuis why is that?

[bnoordhuis]

@gibfahn Because it's vulnerable to race conditions: there is a time window between the check and the use where the resource can change or disappear. Every TOCTOU bug ever is a variation on that theme.

@mrpeu No problem, hope it's working for you now.

[gireeshpunathil]

Doesn't the current code follow TOCTOU? (though the window between TOC and TOU is narrow)

Given the error is captured right and only issue is with the error message, how about making this explicit in the doc?

[RikkiGibson]

Could you do a check after the fact simply for the purpose of giving a better error message? i.e. if you get an ENOENT, check if the cwd exists, if not then give an error message specific to that. In the worst case you provide a wrong error message, but not a wrong program behavior.

[ctday]

Still happening to me. Is there at least a manual way to work around this? Ubuntu on armv7.

[sam-github]

@ctday You can check after the fact whether it is the cwd or the node executable that is ENOENT (use fs.stat()).

[ctday]

Ok, thanks.

[github-actions]

There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.

For more information on how the project manages feature requests, please consult the feature request management document.

[github-actions]

There has been no activity on this feature request and it is being closed. If you feel closing this issue is not the right thing to do, please leave a comment.

For more information on how the project manages feature requests, please consult the feature request management document.