Accept process.execPath as-is

[saper]

Remove red tape surrounding process.execPath
and use it as-is. In particular, do not try
to canonicalize the path returned by
process.execPath as this might be relative
in the restricted Linux environments
(for example using overlayfs).

We should be prepared to accept relative
or otherwise broken process.execPath and
have a faith it works (otherwise our
build scripts wouldn't be invoked
in the first place).

#1323

[saper]

After a little consideration this is not a bug in the node's fs module either; process.execPath should be considered existing relative to the OS-dependent PATH resolution mechanism and not relative to the current directory wherever our scripts may be executed. In other words, we try to fs.lstatSync('node') with a current directory that does not have a file named node at all and we correctly get ENOENT in return.

[xzyfer]

Are you sure this isn't introducing a regression? I recall this being added for specific reason.

#668

[saper]

I am never sure, I always check. Without libuv/libuv#293 (or similar) merged we are just getting the working path to the executable - we do not care here at all whether it is symlinked or pulled out of the moon. Even relative path will work here as long as it is in some directory on PATH. (See even worse problem on OpenBSD libuv/libuv#652). We just want to call "node", preferably the one we are called with. There is no superportable way to do this 100% correctly, but this approach will work.

Next time I'll boot my Windows box I'll check of course.

[Mischi]

👍

I've verified that this PR would fix node-sass on OpenBSD if process.execPath is relative.

[xzyfer]

On further thought this makes sense.