Nvm-windows: nvm funktioniert nicht in 32/64-Bit-Situationen für Windows 7
Meine Umgebung
- [X] Windows 7 oder niedriger (aufgrund von EOL nicht wirklich unterstützt)
- [ ] Windows 8
- [ ] Windows 8.1
- [] Windows 10
- [] Windows 10 IoT Core
- [] Windows Server 2012
- [] Windows Server 2012 R2
- [] Windows Server 2016
[] Meine Windows-Installation ist nicht englisch.
Ich habe schon...
[X] Lesen Sie die README-Datei, um sich über npm-Fallstricke und Antivirenprobleme zu informieren.
- [X] hat das Wiki überprüft, um sicherzustellen, dass mein Problem noch nicht behoben wurde.
- [X] hat bestätigt, dass ich ein Konto mit Administratorrechten verwende.
- [X] hat die Probleme (offen und geschlossen) durchsucht, um sicherzustellen, dass dies kein Duplikat ist.
[X] hat sichergestellt, dass dies keine Frage zur Verwendung von NVM für Windows ist, da Gitter für Fragen und Kommentare verwendet wird.
Mein Problem bezieht sich auf (überprüfen Sie nur die zutreffenden):
[] settings.txt
- [] Proxy-Unterstützung
- [X] 32- oder 64-Bit-Unterstützung
Erwartetes Verhalten
Ich verwende Windows 7/64 Bit
Ich habe (mit admin priv) den NVM für Windows 1.1.1 installiert. Von dort habe ich verwendet
nvm install 6.1.0 all
nvm install 6.3.0 all
Ich habe dann angerufen
nvm list
ergebend
C:\Users\kagentes>nvm list
6.3.0
6.1.0
Ich rannte dann
nvm use 6.3.0 64
und dann
node -v
und erwartet zu bekommen
v6.3.0
Tatsächliches Verhalten
Beim Laufen
node -v
Ich bekomme
'node' is not recognized as an internal or external command,
operable program or batch file.
Auch nach dem Setzen des Befehls nvm use stelle ich fest, dass die Liste nicht zu bestätigen scheint, dass der Befehl "use" funktioniert. Wie in:
C:\Users\kagentes>nvm use 6.3.0 64
Now using node v6.3.0 (64-bit)
C:\Users\kagentes>nvm list
6.3.0
6.1.0
Aus den Screenshots auf der Seite https://github.com/coreybutler/nvm-windows geht hervor, dass der Befehl nvm list unten ungefähr so etwas zurückgeben sollte (aber ich bekomme das NICHT ).
C:\Users\kagentes>nvm list
* 6.3.0 (In Use)
6.1.0
Es hat weder das Sternchen noch die Anzeige "In Verwendung".
Möglicherweise hilft dies auch bei der Diagnose des Problems, aber wenn ich den Befehl nvm arch ausführe, erhalte ich die folgenden seltsamen Ergebnisse, unabhängig davon, was ich in nvm use :
C:\Users\kagentes>nvm arch
System Default: 64-bit.
Currently Configured: -bit.
Schritte zum Reproduzieren des Problems:
Schritte zur Reproduktion sind bereits im Abschnitt über das erwartete Verhalten angegeben. Ich habe bereits mögliche Empfehlungen in anderen Problemen ausprobiert, z. B. in Problem Nr. 146, sowie den Neustart der Shell, den Neustart des Computers und die Sicherstellung, dass alles mit Administratorrechten ausgeführt wurde. Bevor ich damit anfing, habe ich frühere Versionen von Node deinstalliert, die sich auf dem Computer befanden. (dann installierte nvm-windows und befolgte deine anweisungen).
corvinrok
Alle 10 Kommentare
Es tut mir leid, die offensichtliche Frage zu stellen, aber haben Sie versucht, das Terminalfenster neu zu starten? Unter Win7 erstickt es manchmal immer noch, wenn Sie zum ersten Mal versuchen, eine bestimmte Version (mklink) zu verwenden.
coreybutler
am 18. Juli 2016
Ja, habe ich. Ich habe versucht, das Terminalfenster neu zu starten. Dann hat sogar die Maschine das Ergebnis nicht geändert.
corvinrok
am 18. Juli 2016
OK - ich werde das untersuchen, wenn ich Zeit habe. Leider komme ich mit Win7 nicht oft herum.
coreybutler
am 18. Juli 2016
Für alle als Referenz zu Win7: https://github.com/coreybutler/nvm-windows/wiki/Support-for-Windows-7-and-Earlier
coreybutler
am 18. Juli 2016
@kgentes - Ich
Stellen Sie nach der Deinstallation des Knotens sicher, dass das Verzeichnis, in dem der Knoten ursprünglich installiert wurde, entfernt und nicht nur leer ist. Für Windows 7, 64-Bit, ist die Standardeinstellung "C: Program Filesnodejs".
Wenn das Verzeichnis "nodejs" noch vorhanden ist, kann der Befehl "nvm use" unter der Kontrolle von nvm keine symbolische Verknüpfung zur Knotenversion herstellen.
Ich hatte das gleiche Problem, bis ich das Verzeichnis "nodejs" manuell löschte.
hoffentlich hilft das
pleverett
am 19. Juli 2016
Danke @pleverett . Ich werde es bald versuchen. Ich schätze die Köpfe hoch.
corvinrok
am 20. Juli 2016
@pleverett DANKE SIR! Das hat so funktioniert, wie Sie es angekündigt haben! Superartig! Dieser Thread kann geschlossen werden. Sollte wahrscheinlich als Lösung für zukünftige Windows 7-Benutzer markiert werden (nicht sicher, ob dies möglich ist, hier bin ich neu in diesem Ökosystem), die möglicherweise auf dieses Problem stoßen. NVM für Windows funktioniert jetzt nahtlos, nachdem ich das Verzeichnis "C: Program Filesnodejs" ("C: Programme (x86) nodejs" für 32-Bit) entfernt habe, das vom Deinstallationsprogramm anscheinend nicht standardmäßig entfernt wird. Zusammen mit diesem Verzeichnis habe ich auch entfernt:
- "C: UsersusernameAppDataRoamingnpm"
- "C: UsersusernameAppDataRoamingnpm-cache"
Obwohl das wohl nicht nötig war.
Wie auch immer, alles funktioniert. Vielen Dank!
corvinrok
am 21. Juli 2016
@pleverett @coreybutler
ein anderes verwandtes Problem ---
Jetzt, da ich Versionen von Node über NVM sehen und ändern kann, frage ich mich, ob ich beim Ausführen der folgenden Ergebnisse unterschiedliche Ergebnisse sehen sollte:
npm config list
Im Moment ändert sich keine der Informationen außer der einen Variablen darunter.
user-agent = "npm/3.10.3 node/v6.3.0 win32 ia32"
alle anderen bleiben gleich. Und es scheint, dass es nur eine Version von global installierten Knotenmodulen gibt.
Wenn ich nur von der 64-Bit-Version von 6.3.0 auf die 32-Bit-Version von 6.3.0 wechsle, habe ich dann dieselben globalen Knotenmodulinstallationen? oder wird es unterschiedliche machen? Oder muss ich eine Versionsänderung vornehmen, um verschiedene global installierte Knotenmodule zu erhalten? Im Idealfall würde ich denken, dass es für jede Bitversion einen eindeutigen Kontext beibehalten würde (aufgrund nativer Knotenmodule wie libxml - ??? usw.), aber ich kann sehen, warum andere es möglicherweise nicht so mögen.
Benutze ich es immer noch falsch? oder ist das ein verwandter Fehler?
corvinrok
am 22. Juli 2016
Da dies immer noch auf demselben Thread funktioniert, wollte ich dies erneut öffnen, anstatt ein neues Problem zu erstellen ... [siehe vorherigen Kommentar für meinen aktualisierten Status]
corvinrok
am 22. Juli 2016
@kgentes - Es tut mir leid, dass ich das verpasst habe ... es sollte wahrscheinlich ein anderes Problem sein.
Wenn Sie nur von 32-> 64-Bit oder umgekehrt wechseln, verwendet NVM4W dasselbe globale Verzeichnis node_modules . Dies wurde absichtlich gemacht, hauptsächlich um den gesamten Footprint der Node-Umgebung auf ein Minimum zu beschränken. Wenn Sie separate Installationsverzeichnisse für beide 32/64-Bit-Versionen haben, verdoppelt sich der Platzbedarf der meisten Benutzer ... und der gesamte Platzbedarf ist etwas, woran die meisten Benutzer erst denken, wenn ihnen der Speicherplatz ausgeht. Trotzdem neige ich sowieso dazu, ein individuelles Installationsverzeichnis nach Version + Proc-Architektur zu verwenden. Es sollte wirklich Sache des Benutzers sein, und wie Sie sagten, werden dadurch einige native Pakete zerstört.
Ich schließe dies, da das Thema etwas anders ist. Wenn Sie möchten, können Sie gerne eine neue Ausgabe eröffnen.
coreybutler
am 3. Nov. 2016
Verwandte Themen
thany
·
4Kommentare
Deilan
·
4Kommentare
petrovicz
·
4Kommentare
leiamac
·
4Kommentare
AllainPL
·
7Kommentare
Hilfreichster Kommentar
@kgentes - Ich
Stellen Sie nach der Deinstallation des Knotens sicher, dass das Verzeichnis, in dem der Knoten ursprünglich installiert wurde, entfernt und nicht nur leer ist. Für Windows 7, 64-Bit, ist die Standardeinstellung "C: Program Filesnodejs".
Wenn das Verzeichnis "nodejs" noch vorhanden ist, kann der Befehl "nvm use" unter der Kontrolle von nvm keine symbolische Verknüpfung zur Knotenversion herstellen.
Ich hatte das gleiche Problem, bis ich das Verzeichnis "nodejs" manuell löschte.
hoffentlich hilft das