@ Черланцизм. введите следующие команды в PowerShell

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned

или же

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope LocalMachine

после запуска вашего сценария PowerShell .ps1

@ Черланцизм
В https://github.com/npm/read-cmd-shim/pull/6 я добавляю только путь извлечения из поддержки powershell.
Эта функция предназначена для https://github.com/npm/cli/pull/281

Если вы хотите узнать, почему при установке пакета добавляется * .ps, см. Это: https://github.com/npm/cmd-shim/pull/34

Сценарии PowerShell также являются единственными, которые обеспечивают встроенный способ передачи стандартного ввода-вывода в процесс Node.js ( https://github.com/npm/cmd-shim/pull/43 ), когда входные данные конвейера были переданы в сценарий.

Только что установил последнюю версию NPM на новую машину, и это очень тревожное поведение, поскольку раньше он работал из коробки.

Решение, предоставленное @ RAJU2529, подходит, если вы можете делать на своем компьютере все, что хотите. На машине, присоединенной к домену, этот параметр может определяться настройками организации и не может быть изменен, даже если пользователь является администратором на машине.
Есть ли у кого-нибудь другой обходной путь, кроме понижения версии NPM?

Удалить все сценарии *.ps1 в каталоге npm bin?

@ ExE-Boss это то, чем я закончил, но это действительно обходной путь ...

Согласитесь и с вышеизложенным. Лучше, чем менять политику выполнения ... Я знаю, что это работает, и все люди, вероятно, будут запускать скрипты, но ... просто глупо

Недавно мы обновили наши серверы сборки до последней версии LTS узла.
Некоторые из наших сценариев PowerShell используют такой код:

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

Если вы спросите PowerShell, какой исполняемый файл он использует ( (Get-Command npm-cli-login).Source ), вы получите только что созданные ps1 -файлы вместо cmd .

Процесс завершается с %1 is not a valid win32 application потому что ps1-скрипт не является допустимым исполняемым файлом.

Это критическое изменение в версии, и его следует как минимум пересмотреть.

Удалить все сценарии *.ps1 в каталоге npm bin?

Есть ли у нас способ заставить Windows не создавать сценарий .ps1 при использовании npm link или npm i -g ../<package> ? Довольно неприятно постоянно заходить в папку npm и убирать этот беспорядок.

Если в вашей системе есть командная строка, один быстрый обходной путь - указать PowerShell использовать вместо нее версию cmd: <package-name>.cmd

Например для TypeScript:
вместо
tsc -v который теперь вызывает tsc.ps1 в PowerShell
использовать
tsc.cmd -v

Если в вашей системе есть командная строка, один быстрый обходной путь - указать PowerShell использовать вместо нее версию cmd: <package-name>.cmd

Да, если вы добавите .cmd powershell использует правильный исполняемый файл.

Но если у вас есть скрипты сборки с поддержкой версий, которые не должны меняться после выпуска, у вас есть только две возможности:

• Все равно измените это
• Не обновляйте узел -> возможная проблема с безопасностью.

Запрос на вытягивание 34, в котором была добавлена ​​эта функция, ссылается на нее как на исправление проблемы 20699 npm. При проверке этой проблемы кажется, что основная проблема заключается в передаче символа амперсанда в качестве аргумента команды в командной строке Windows. Это интерпретируется как разделитель команд, поэтому возникает ошибка.

Однако в командной строке Windows мы можем экранировать символ амперсанда с помощью каретки. ^&

Кратко, но может ли это быть реальной альтернативой тому, что было реализовано, что привело к этим критическим изменениям? Есть ли способ определить, что аргумент предназначен для командной строки и регулярного выражения Windows, или вставить символ каретки в аргумент в качестве выхода? Кто-нибудь вроде босса @ ExE-Boss знает, есть ли причина, по которой мы не могли решить эту проблему, используя что-то подобное?

В следующем документе описывается лучший способ обработки синтаксического анализа аргументов командной строки Windows. Использовать это как руководство?
https://docs.microsoft.com/en-us/archive/blogs/twistylittlepassagesallalike/everyone-quotes-command-line-arguments-the-wrong-way

Я думаю, что каналы также не работают с использованием сценариев ps1, связанных с этим.

Я пробую использовать следующие часто используемые инструменты:
prettyjson
красивее

Например, когда я запускаю на Powershell следующее:
echo '{"a": 1}' | prettyjson

Терминал будет просто ждать ввода до тех пор, пока не будет нажата CTRL + C, и он выйдет без ожидаемого вывода.

Обходной путь - добавить к команде .cmd или вместо этого просто использовать cmd:
echo '{"a": 1}' | prettyjson.cmd

Выходы

a: 1

Мой вопрос о stackoverflow: https://stackoverflow.com/questions/62951533/why-pipes-are-not-working-on-powershell-for-various-nodejs-cli-tools

Обновить

Извините, я только что вспомнил, что это было прокомментировано здесь до https://github.com/npm/cli/issues/470#issuecomment -568165144 о трубопроводе stdin, а PR здесь https://github.com/npm/cmd-shim / тянуть / 43 . Но все же использование .cmd похоже, работает для каналов.