Closed monkpit closed 8 years ago
Thanks for bringing this to attention.
'node' could not be spawned. Is it installed and on your path? If so please open an issue on the package spawning the process.
fixPath was inspired by fix-path npm module and simply adds the default paths (for OS X at least) back to the process so that it can spawn other processes without running into this error. I admit that this solution should not add hard-coded paths but instead add the user's PATH (e.g. using echo $PATH
). @monkpit does PATH work similarly on Windows? If you would like to submit a PR that would be appreciated.jupyter
and jupyter kernelgateway
. If the command is available in one of the paths, then it should work. What is the value of process.env.PATH
when node is not launched from the command line? In Windows, process.env.PATH
will be your system path when the program is launched through the Explorer.
There may be a sanity check to say, fixPath only runs if process.env.PATH == null
or something like that. That way, on Windows it should never run.
Regarding 2., a quick google search brings up netstat -na | find /i "listening"
to list all processes listening on the machine. There may be some permission conflicts here regarding whether a user can see a process being run by another user or administrator.
Sample output looks like so:
TCP 0.0.0.0:80 0.0.0.0:0 LISTENING
TCP 0.0.0.0:111 0.0.0.0:0 LISTENING
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING
TCP 0.0.0.0:2701 0.0.0.0:0 LISTENING
TCP 0.0.0.0:3306 0.0.0.0:0 LISTENING
TCP 0.0.0.0:4445 0.0.0.0:0 LISTENING
TCP 0.0.0.0:5432 0.0.0.0:0 LISTENING
TCP 0.0.0.0:5985 0.0.0.0:0 LISTENING
TCP 0.0.0.0:6002 0.0.0.0:0 LISTENING
TCP 0.0.0.0:7001 0.0.0.0:0 LISTENING
TCP 0.0.0.0:7002 0.0.0.0:0 LISTENING
TCP 0.0.0.0:9217 0.0.0.0:0 LISTENING
TCP 0.0.0.0:17500 0.0.0.0:0 LISTENING
TCP 0.0.0.0:30950 0.0.0.0:0 LISTENING
TCP 0.0.0.0:47001 0.0.0.0:0 LISTENING
TCP 0.0.0.0:47546 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49152 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49153 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49154 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49193 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49789 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49790 0.0.0.0:0 LISTENING
TCP 0.0.0.0:57824 0.0.0.0:0 LISTENING
TCP 0.0.0.0:65343 0.0.0.0:0 LISTENING
TCP 127.0.0.1:843 0.0.0.0:0 LISTENING
TCP 127.0.0.1:3142 0.0.0.0:0 LISTENING
TCP 127.0.0.1:5354 0.0.0.0:0 LISTENING
TCP 127.0.0.1:8745 0.0.0.0:0 LISTENING
TCP 127.0.0.1:17600 0.0.0.0:0 LISTENING
TCP 127.0.0.1:23402 0.0.0.0:0 LISTENING
TCP 127.0.0.1:27015 0.0.0.0:0 LISTENING
TCP 127.0.0.1:57433 0.0.0.0:0 LISTENING
TCP [::]:80 [::]:0 LISTENING
TCP [::]:135 [::]:0 LISTENING
TCP [::]:445 [::]:0 LISTENING
TCP [::]:2701 [::]:0 LISTENING
TCP [::]:3306 [::]:0 LISTENING
TCP [::]:4445 [::]:0 LISTENING
TCP [::]:5432 [::]:0 LISTENING
TCP [::]:5985 [::]:0 LISTENING
TCP [::]:9217 [::]:0 LISTENING
TCP [::]:47001 [::]:0 LISTENING
TCP [::]:47546 [::]:0 LISTENING
TCP [::]:49152 [::]:0 LISTENING
TCP [::]:49153 [::]:0 LISTENING
TCP [::]:49154 [::]:0 LISTENING
TCP [::]:49193 [::]:0 LISTENING
TCP [::]:49789 [::]:0 LISTENING
TCP [::]:49790 [::]:0 LISTENING
TCP [::]:65343 [::]:0 LISTENING
Then to check similar to lsof -i${port}
, maybe just combine another find
command in there:
netstat -na | find /i "listening" | find /i "${port}"
So from my output before, if port=80
the output is:
TCP 0.0.0.0:80 0.0.0.0:0 LISTENING
TCP [::]:80 [::]:0 LISTENING
and if port=8888
the output is blank.
It seems like the path issue only affects OS X, so I put this inside of a conditional. I also switched from using lsof
to netstat
. Can you try clone the fix-path branch, apm install
, apm link
and test on Windows before I push to master? (Be sure to 'apm unlink' afterwards to continue using the version managed by Atom).
To answer your question, the process.env.PATH that is available when launching any app from the Dock, Finder, Spotlight, etc. (any way other than command line) on OS X appears to be usr/bin:bin:usr/sbin:sbin
which doesn't include usr/local/*
where many binaries are located including jupyter. I'm surprised this hasn't been patched in atom-core yet, but we can patch it in the package by simply adding these default paths back to process.env.PATH.
Just published 0.0.5. Update and let us know what happens...
Sorry for the late reply, I don't always have access to my windows box. The fix you submitted works for me, I can keep my path variables after loading jupyter-notebook.
There are several issues preventing this package from running on Windows.
The most noticeable is the
fixPath()
function that runs when the package starts - this has the side effect of completely breaking any other package that relies upon your PATH variable, like linters, compilers, etc. I can't tell what it is actually trying to fix, or I'd submit a pull request with a patch.I would suggest not relying upon hard-coded path separators like
.split(':')
- userequire('path').delimiter
instead.In
notebook-editor.js
, I would try to avoid relying uponlsof -i:${port}
, as this is not a portable command.That's just a few observations, I can't get
kernelgateway
to get called from atom-notebook correctly so I can't even run the package after making changes. A setting to define where my jupyter-kernelgateway or base jupyter binaries exist would be nice.