@Cerlancism. Geben Sie die folgenden Befehle in Powershell ein

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned

oder

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope LocalMachine

Nachdem Sie Ihr .ps1 PowerShell-Skript ausgeführt haben

@Cerlancism
In https://github.com/npm/read-cmd-shim/pull/6 füge ich nur einen Extraktpfad aus der Powershell-Unterstützung hinzu.
Diese Funktion ist für https://github.com/npm/cli/pull/281

Wenn Sie wissen möchten, warum * .ps bei der Installation des Pakets hinzugefügt wird, lesen Sie bitte Folgendes: https://github.com/npm/cmd-shim/pull/34

PowerShell- Skripte sind auch die einzigen, die eine integrierte Möglichkeit bieten, stdin in den Node.js- Prozess ( https://github.com/npm/cmd-shim/pull/43 )

Ich habe gerade das neueste NPM auf einer neuen Maschine installiert und dies ist ein sehr störendes Verhalten, während es früher sofort funktioniert hat.

Die von @ RAJU2529 bereitgestellte
Hat jemand eine andere Problemumgehung, außer das Herabstufen der NPM-Version?

Alle *.ps1 Skripte im Verzeichnis npm bin

@ ExE-Boss, das habe ich vorerst beendet, aber es ist wirklich eine Problemumgehung ...

Stimmen Sie auch dem oben Gesagten zu. Besser als Ihre Ausführungsrichtlinie zu ändern ... Ich weiß, dass es funktioniert und alle und die Leute wahrscheinlich Skripte ausführen, aber ... einfach völlig albern

Wir haben kürzlich unsere Build-Server auf die neueste LTS des Knotens aktualisiert.
Einige unserer PowerShell-Skripte verwenden Code wie:

Start-Process "npm-cli-login" [...] -NoNewWindow

Wenn Sie Powershell fragen, welche ausführbare Datei verwendet wird ( (Get-Command npm-cli-login).Source ), erhalten Sie die neu erstellten ps1- Dateien anstelle der cmd .

Der Prozess wird mit %1 is not a valid win32 application da ein ps1-Skript keine gültige ausführbare Datei ist.

Dies ist eine bahnbrechende Änderung innerhalb einer Version und sollte zumindest überprüft werden.

Alle *.ps1 Skripte im Verzeichnis npm bin

Haben wir eine Möglichkeit, Windows zu zwingen, das Skript .ps1 nicht zu erstellen, während npm link oder npm i -g ../<package> ? Es ist ein bisschen frustrierend, in den npm-Ordner zu gehen und dieses Chaos die ganze Zeit zu beseitigen.

Eine schnelle Problemumgehung, wenn Ihr System über eine Eingabeaufforderung verfügt, besteht darin, PowerShell anzuweisen, stattdessen die cmd-Version zu verwenden: <package-name>.cmd

Zum Beispiel für TypeScript:
Anstatt von
tsc -v das jetzt tsc.ps1 in PowerShell aufruft
verwenden
tsc.cmd -v

Eine schnelle Problemumgehung, wenn Ihr System über eine Eingabeaufforderung verfügt, besteht darin, PowerShell anzuweisen, stattdessen die cmd-Version zu verwenden: <package-name>.cmd

Ja, wenn Sie .cmd Powershell hinzufügen, wird die richtige ausführbare Datei verwendet.

Wenn Sie jedoch Build-Skripte versioniert haben, die sich nach einer Veröffentlichung nicht ändern sollten, haben Sie nur zwei Möglichkeiten:

• Ändere es trotzdem
• Knoten nicht aktualisieren -> mögliches Sicherheitsproblem.

Die Pull-Anforderung 34, die diese Funktion hinzugefügt hat, verweist darauf als Fix für das npm-Problem 20699 . Wenn Sie dieses Problem überprüfen, scheint das Hauptproblem darin zu bestehen, das kaufmännische Und als Befehlsargument in der Windows-Befehlszeile zu übergeben. Dies wird als Befehlsbegrenzer interpretiert, sodass Fehler auftreten.

In der Windows-Befehlszeile können wir dem kaufmännischen Und-Zeichen jedoch mit einem Caret entkommen. ^&

Longshot, aber könnte dies eine praktikable alternative Lösung zu dem sein, was implementiert wurde, um diese bahnbrechenden Änderungen einzuführen? Gibt es eine Möglichkeit, zu erkennen, dass ein Argument für die Windows-Befehlszeile bestimmt ist, und das Caret-Zeichen als Escapezeichen neu zu formulieren oder in das Argument einzufügen? Weiß jemand wie @ ExE-Boss-Chef, ob es einen Grund gibt, warum wir dieses Problem nicht mit etwas Ähnlichem hätten lösen können?

Das folgende Dokument beschreibt die beste Methode zum Parsen von Windows-Befehlszeilenargumenten. Verwenden Sie es als Leitfaden?
https://docs.microsoft.com/en-us/archive/blogs/twistylittlepassagesallalike/jeder-quotes-command-line-arguments-the-wrong-way

Ich denke, Pipes funktionieren auch nicht mit ps1-Skripten, die damit zusammenhängen.

Ich probiere die folgenden häufig verwendeten Tools aus:
Prettyjson
schöner

Zum Beispiel, wenn ich auf Powershell Folgendes ausführe:
echo '{"a": 1}' | prettyjson

Das Terminal wartet nur so lange auf Eingaben, bis STRG + C gedrückt wird, und es wird ohne erwartete Ausgabe beendet.

Die Problemumgehung besteht darin, dem Befehl .cmd hinzuzufügen oder stattdessen einfach cmd zu verwenden:
echo '{"a": 1}' | prettyjson.cmd

Ausgänge

a: 1

Meine Frage zu Stackoverflow: https://stackoverflow.com/questions/62951533/why-pipes-are-not-working-on-powershell-for-various-nodejs-cli-tools

Aktualisieren

Entschuldigung, ich habe mich gerade daran erinnert, dass es hier vor https://github.com/npm/cli/issues/470#issuecomment -568165144 über stdin piping kommentiert wurde und die PR hier https://github.com/npm/cmd-shim ist / pull / 43 . Trotzdem scheint die Verwendung von .cmd für Pipes zu funktionieren.