-
Notifications
You must be signed in to change notification settings - Fork 28.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Windows: node.cmd shortcut instead of full-blown node.exe #871
Comments
I agree that this would be a nice, however the issue is that Using a batch file would also make it impossible to obtain the pid of "node", which makes IPC stdio streams nonfunctional. Also note that on windows |
@piscisaureus, thank you for the clarification. Aside, I am sorry but I am not sure how else to test :: this is cmd on Windows 8.1
$ nvmw install iojs-v1.2.0
...
$ nvmw use iojs-v1.2.0
Now using iojs v1.2.0
$ iojs -v
v1.2.0
$ iojs
> var child_process = require('child_process');
> child_process.spawn('c:/users/adeel/.nvmw/iojs/v1.2.0/node.cmd', ['-p', 'process.execPath']).stdout.on('data', function(e){console.log('data: ' + e)})
...
...
> data: c:\Users\Adeel\.nvmw\iojs\v1.2.0\iojs.exe
(^C again to quit)
>
$ node -v
v1.2.0
$ node
> var child_process = require('child_process');
> child_process.spawn('c:/users/adeel/.nvmw/iojs/v1.2.0/node.cmd', ['-p', 'process.execPath']).stdout.on('data', function(e){console.log('data: ' + e)})
...
...
> data: c:\Users\Adeel\.nvmw\iojs\v1.2.0\iojs.exe Apparently, |
😲 I just tried your test case and, I can confirm it works. But it shouldn't work! According to msdn, "to run a batch file, you must start the command interpreter; set lpApplicationName to cmd.exe and set lpCommandLine to the following arguments: /c plus the name of the batch file." There is no way iojs is prepending 'cmd /c' when Am I dreaming? Is it the drugs? |
I think I figured out what happened. Windows A relatively recent security fix (in response to CVE-2014-0315) hard-coded the full path to cmd.exe into CreateProcess, which makes it work. There are still significant issues with running .bat files.
|
I do not know why but I am not getting this error: "arguments are mangled" even after moving The last line created file named 3 in the cwd (with Perhaps, I have something in the path which is remedying it from happening. Here is the
|
|
My bad. I thought that was the actual output. 😄 |
Instead of installing node as a symlink to iojs.exe, why don't we simply install the binary twice, with two different names? It avoids all the downsides of symlinks, and preserves all the upsides of having iojs available under both names. On unix, symlinks (and hard links) work well for this kind of thing, I'm wondering if we went too far down the "do it like unix on windows" path. |
Right now the two files are hard linked. It saves some space - probably so little that it's unnoticeable. Other than that, it should behave as if there were two copies of the same file. |
I'm a bit lost then as to what the problem is, and pretty nervous about replacing with a @am11 what problem are you trying to solve? |
@sam-github, as noted earlier, the issue is described here: appveyor/ci#139. The AppVeyorCI for Windows is using node.exe provided by io.js distribution in addition to iojs.exe, as you guys are recommending. As you can see there, it took some hit and trial to narrow down the issue to this:
Since node.cmd for Windows is a no-go, we will probably have to somehow inject this node.cmd into their iojs install folder and delete the node.exe (if it is even a permitted action) to successfully run io.js job on AppVeyor. |
Sorry, not really understanding the problem.
Not following at all. You clearly already have two packages that contain a node.exe (v0.10 and v0.12), why is a third package (v1.x) a problem? Threading through the link, it all seems to stem from the assumption that io.js and node are so different, they can be distinguished based on executable name: Why do that? Use version. 1.x is io.js, 0.10 and 0.12 are node... personally, I'd call them both "node". By the time joyent/node gets to 1.x in a couple years, iojs and it will have merged, and if not, then deal with the runtime distinction in a couple years, don't cause yourself this pain now. Or wait a while, and use |
@sam-github, we need to distinguish the runtimes to name our binaries for many-runtimes, various-platforms matrix, and publish on a separate repo: https://github.com/sass/node-sass-binaries/. On install, we reconstruct the name and download the matching binary from that repo. I started with this PR: rvagg/archived-pangyp#1 and I do agree that our weird runtime detection is not the ideal way, but that is not causing of this issue; because even if we hardcode |
Generally, this is what I have narrowed it down to: If you built the binary like this: # this is PS
iojs node_modules/pangyp/bin/node-gyp configure # optional
iojs node_modules/pangyp/bin/node-gyp build It will execute perfectly with Also related: sass/node-sass#708 (comment) |
This turned out to be the same issue as #751. |
In io.js dist, node.exe is provided as a separate executable which is confusing and causes problems if your script is relying on
process.execPath
and your intention is to runiojs
vianode
alias (npm task etc.).For Linux, io.js provides a (4bytes) symlink called
node
which points to iojs inbin/
dir. On Windows we can also create a symlink, and resolve to real executable (like this) but since Windows symbolic links are not sharable FS objects, and they actually reflect the real path if you try to move, copy or package it to a zip. Meaning you cannot copy/paste Windows symlink itself (like shortcut (.lnk
) files), it will copy the original file instead.Having said that, here is a proposed solution:
Inspired by nvmw, which downloads only iojs.exe and then makes a copy of
alias-node.cmd
tonode.cmd
in iojs version installation directory like this: nvmw.bat#L170, where alias-node.cmd has the canned content:Please add this
node.cmd
in io.js distro in place ofnode.exe
.Related: appveyor/ci#139.
The text was updated successfully, but these errors were encountered: