hakobera
Persist choice from 'nvmw use [...]'
With these changes nvmw use [iojs|node] will persist in system path accross cmd's sessions.
As quickly discussed in #42.
Here are the steps :
- clean path from special characters
- remove previous
.nvmwpaths - add back special characters
- determine which iojs or node to get
- set PATH and NODE_PATH in System Path (won't work if System Path is more than 1024 characters, silly windows)
- set PATH and NODE_PATH in current cmd's session
Let me now if this is useful to anyone else.
Is there any reason why you are modifying the system path (with the risk of breaking it by exceeding 1024 chars)? Persisting across sessions would work without setting the system path, right?
Setting it in the System Path is what makes it persistent across sessions.
Otherwise it won't be persistent, we could also put it into the User Path (by removing /M flag), and the result would be the same, because User Path gets merged into System Path in an environment point of view.
Then, if we exceed 1024 chars, System Path won't be updated, it will stay how it was before we tried to modify it. So we're safe here. It will just follow the same behavior as before.
Depends on what you mean with session. If you mean across different users' sessions then yes, otherwise the user path is enough. I wouldn't fiddle with the system path cause it can easily break (which just happened to me by using this PR). Great job here though.
Oh sorry for your Path, what happened?
I'll try to see if I can set it into the User Path instead.
Nothing too bad, just exceeded 1024 chars and got trimmed at the end. Considering that the limit is easily exceeded I would definitely not mess up with the system path. Do you think you can change it? I think setting the user path is more than enough for all practical purposes.
On Fri, Feb 20, 2015 at 3:22 PM, Yoann Moinet [email protected] wrote:
Oh sorry for your Path, what happened?
I'll try to see if I can set it into the User Path instead.
— Reply to this email directly or view it on GitHub https://github.com/hakobera/nvmw/pull/43#issuecomment-75244813.
I agree with you. I really thought that by exceeding 1024 chars it wouldn't apply the modification. Really sorry for that.
I'll check this evening for the User Path.
No worries, I'm grateful that you've been doing this actually!
On Fri, Feb 20, 2015 at 3:27 PM, Yoann Moinet [email protected] wrote:
I agree with you. I really thought that by exceeding 1024 chars it wouldn't apply the modification. Really sorry for that.
I'll check this evening for the User Path.
— Reply to this email directly or view it on GitHub https://github.com/hakobera/nvmw/pull/43#issuecomment-75245672.
Ok, now it should persit into User Path instead. We don't touch to System Path anymore. It was way harder than I thought :weary:
Not there yet unfortunately
Now using node v0.10.36 x64
find: /i: No such file or directory
How did you get this error? Can't reproduce it on my side. Do you have repro-steps?
Not really, I just pulled-in your changes, got rid of the entries pointing at the .nvmw folder in the system path and I started getting this error. Maybe you still have those entries in the system path?
On Sun, Feb 22, 2015 at 12:28 AM, Yoann Moinet [email protected] wrote:
How did you get this error? Can't reproduce it on my side. Do you have repro-steps?
— Reply to this email directly or view it on GitHub https://github.com/hakobera/nvmw/pull/43#issuecomment-75399236.
Do you have Cygwin installed?
Sometimes, find from Cygwin can interfer with the cmd's.
I may have found a fix for this.
I have Git for Windows installed and its bin folder in the path, which includes find.exe. So yes, that might be the issue, although I would say quite a common one, considering that most people using nvmw will probably be in my same condition.
On Sun, Feb 22, 2015 at 12:44 AM, Yoann Moinet [email protected] wrote:
Do you have Cygwin installed? Sometimes, find from Cygwin can interfer with the cmd's. I may have found a fix for this http://stackoverflow.com/questions/19642548/batch-find-command-not-working .
— Reply to this email directly or view it on GitHub https://github.com/hakobera/nvmw/pull/43#issuecomment-75399935.
Let me know if that fix your problem.
I am now using find via %windir%\system32\FIND.exe.
So it can't be conflicted with anything else.
I hope it's the only one.
No wait, there must be something wrong in the script, it works the first time I run in within a console session, then it fails:
C:\Users>nvmw use 0.12.0 Now using node v0.12.0 x64
C:\Users>nvmw use 0.12.0 Now using node v0.12.0 x64 find: /i: No such file or directory find: .nvmw: No such file or directory
On Sun, Feb 22, 2015 at 12:48 AM, Yoann Moinet [email protected] wrote:
Let me know if that fix your problem. I am know using fix via %windir%\system32\FIND.exe. So it can't be conflicted with anything else.
— Reply to this email directly or view it on GitHub https://github.com/hakobera/nvmw/pull/43#issuecomment-75400099.
Is it still applying correct changes into the user path? It could be just a warning saying that there is no '.nvmw' reference found. If it's that, I could simply hide it. On Feb 21, 2015 6:52 PM, "Simone Busoli" [email protected] wrote:
No wait, there must be something wrong in the script, it works the first time I run in within a console session, then it fails:
C:\Users>nvmw use 0.12.0 Now using node v0.12.0 x64
C:\Users>nvmw use 0.12.0 Now using node v0.12.0 x64 find: /i: No such file or directory find: .nvmw: No such file or directory
On Sun, Feb 22, 2015 at 12:48 AM, Yoann Moinet [email protected] wrote:
Let me know if that fix your problem. I am know using fix via %windir%\system32\FIND.exe. So it can't be conflicted with anything else.
— Reply to this email directly or view it on GitHub https://github.com/hakobera/nvmw/pull/43#issuecomment-75400099.
— Reply to this email directly or view it on GitHub https://github.com/hakobera/nvmw/pull/43#issuecomment-75400514.
Only the first time it is executed in a shell, the following times it fails if run again. Can you reproduce it?
I can't reproduce it. But it could be a simple warning log. Are the changes still applied onto the User Path?
As I said, only the first time it is run within a console session, the following times it fails
Oh, sorry, I mis-understood your previous comment. I'm trying to reproduce it.
So, I've tried with a clean install, a clean Path with no reference to .nvmw whatsoever.
I've used nvmw first from the installation folder and it gets added to User Path correctly.
Then I've tried multiple combinations, installing, uninstalling, switching between version, between iojs and node.
No luck, I cannot find a way to reproduce your issue.
Can you show me what you've installed with nvmw? nvmw ls
I'm a little out of idea, it's quite hard to fix what I cannot reproduce, maybe we'll have to wait for someone else to test it, see if they can reproduce it.
Ok thanks for the effort, I'll try to figure out why it fails and get back to you then.
On Sun, Feb 22, 2015 at 5:43 PM, Yoann Moinet [email protected] wrote:
So, I've tried with a clean install, a clean Path with no reference to .nvmw whatsoever. I've used nvmw first from the installation folder and it gets added to User Path correctly. Then I've tried multiple combinations, installing, uninstalling, switching between version, between iojs and node. No luck, I cannot find a way to reproduce your issue.
Can you show me what you've installed with nvmw? nvmw ls
I'm a little out of idea, it's quite hard to fix what I cannot reproduce, maybe we'll have to wait for someone else to test it, see if they can reproduce it.
— Reply to this email directly or view it on GitHub https://github.com/hakobera/nvmw/pull/43#issuecomment-75444173.
Ok I think I found the root cause, although I didn't look into the details yet. It has to do with what you mentioned earlier, issues with Git's find.exe. I have Git's bin directory in the path, and it basically seems to depend on the order of inclusion compared to the system directory.
The reason why it worked the first time and then stopped working after the first nvmw use is that the script apparently modified the path in a way that gave Git's find precedence over Windows' find. Didn't figure out how exactly though. The fix seems to have been moving Git's bin folder at the end of system's path. The script now seems to work fine, but maybe (if at all possible) it's better to come up with a general solution, which doesn't depend on whatever find.exe it, (ehm..) finds first!
It could definitely be the problem. But I thought my latest commit would fix this by referencing 'find' via its absolute path.
I didn't try the last commit, I didn't know there was one. I'll check it out. On 22 Feb 2015 19:55, "Yoann Moinet" [email protected] wrote:
It could definitely be the problem. But I thought my latest commit would fix this by referencing 'find' via its absolute path.
— Reply to this email directly or view it on GitHub https://github.com/hakobera/nvmw/pull/43#issuecomment-75450923.
Looks good to me now. Thanks a lot!
On Sun, Feb 22, 2015 at 8:03 PM, Simone Busoli [email protected] wrote:
I didn't try the last commit, I didn't know there was one. I'll check it out. On 22 Feb 2015 19:55, "Yoann Moinet" [email protected] wrote:
It could definitely be the problem. But I thought my latest commit would fix this by referencing 'find' via its absolute path.
— Reply to this email directly or view it on GitHub https://github.com/hakobera/nvmw/pull/43#issuecomment-75450923.
This is going to be a nice addition! :+1:
won't work if System Path is more than 1024 characters, silly windows
Isn't it even less; 260 char limit? We can't be too optimistic about Windows. :wink:
Thanks @am11.
The 260 char limit is for file paths, not system path. Meaning that your file can't be too deep into a directory.
For the system path, it is actually 2048 but we bypass this limitation by setting the user path via the registry instead.