Это не решение с PowerShell, но у меня была та же проблема, за исключением MINGW64. Я обошел это, переключившись на подсистему Windows для Linux (что я все равно хотел сделать) в качестве своего терминала, просто в общем и в VSCode. Этот пост описывает это хорошо:

Как настроить VS Code (Windows) для использования приложения Ubuntu в качестве терминала

В итоге:

1) Установите Ubuntu из магазина приложений Windows.

2) Измените bash по умолчанию с CMD -> wslconfig /setdefault Ubuntu

--- Для VSCode

3) Перезапустите VSCode

4) В VSCode измените "terminal.integrated.shell.windows" на "C:\WINDOWS\System32\bash.exe" (подробнее см. пост выше)

Теперь работает без сбоев в VSCode и WSL (Bash в Ubuntu в Windows). Может быть, по крайней мере, временное решение для вас.

Может быть, вы можете попробовать открыть командную строку с правами администратора. (Запустить от имени администратора). Работает для меня большую часть времени.

Насколько я могу судить, это было вызвано конфликтом с версией Python 3.7, недавно добавленной в Магазин Windows. Похоже, это добавило две «заглушки» с именами python.exe и python3.exe в папку %USERPROFILE%\AppData\Local\Microsoft\WindowsApps, и в моем случае это была вставленная до запись моего существующего исполняемого файла Python в PATH.

Перемещение этой записи ниже правильной папки Python (частично) устранило проблему.

Вторая часть исправления заключается в том, чтобы ввести manage app execution aliases в строку поиска Windows и полностью отключить версии Python из магазина.

Возможно, вам нужно будет сделать только вторую часть, но в моей системе я внес оба изменения, и теперь все вернулось в норму.

Исследование

Все файлы в %USERPROFILE%\AppData\Local\Microsoft\WindowsApps являются заполнителями, которые указывают на файлы, которые фактически находятся где-то в C:\Program Files\WindowsApps, которым полностью запрещены разрешения.

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

"Seems like they didn't really think about the distribution method screwing with permissions!"

Источник: Не удается установить pylint в Git Bash в Windows (Магазин Windows)

Разрешения по-царски облажались из-за метода распространения WindowsApps:

Интересно, что в нем говорится, что группа «Пользователи» может читать и выполнять файлы, а также мой конкретный пользователь, но группа «Администраторы» может только отображать содержимое папки по какой-то смешной непостижимой причине. И при попытке получить доступ к папке в проводнике он отказывается даже показывать содержимое папки, так что в этом тоже есть что-то подозрительное.

Интересно, что хотя выполнение python в CMD работает нормально, папка «WindowsApps» не отображается при перечислении файлов в каталоге, в котором она находится, и при попытке перейти в папку возникает ошибка «Отказано в доступе»:

Попытка изменить разрешения требует сначала смены владельца, поэтому я изменил владельца на группу «Администраторы». После этого я попытался изменить разрешения для группы «Администраторы», включив в них «Полный доступ», но изменить это не удалось, потому что «доступ был запрещен» (да, Micro$ucks, вот что мы пытаемся изменить!).

Эта ошибка разрешения произошла для такого количества файлов, что я использовал Alt + C, чтобы быстро нажать «Продолжить» в повторяющихся сообщениях, но это все равно заняло слишком много времени, поэтому я отменил процесс, в результате чего появилось это предупреждающее сообщение:

И теперь я не могу снова установить пользователя TrustedInstaller в качестве владельца папки WindowsApps, потому что он не отображается в списке пользователей/групп/встроенных принципов безопасности/других объектов. *

* На самом деле, согласно этот учебник, вы можете поменять владельца обратно на TrustedInstaller, введя NT Service\TrustedInstaller в текстовое поле имени объекта.

Решение

Нет решения. В общем, мы совсем запутались. Классный ход, Microsoft.

Похоже, это ограничение в git-bash. Рекомендация использовать winpty python.exe сработала для меня. См. Python не работает в командной строке git bash для получения дополнительной информации.

сэкономить ваше время: используйте wsl and vscode remote extension для правильной работы с python даже с win10 и не забывайте virtualenv! полезный https://linuxize.com/post/how-to-install-visual-studio-code-on-ubuntu-18-04/

Самое простое, что можно сделать, это изменить переменные среды PATH и PYTHONPATH, чтобы убедиться, что папка, содержащая правильные двоичные файлы Python, ищется перед локальной папкой WindowsApp. Вы можете получить доступ к переменным среды, открыв панель управления и выполнив поиск «env».

Добавление локального пути Python до того, как WindowsApps решили проблему.

Эта проблема слишком распространена, чтобы оставаться постоянной. И большинство ответов и инструкций не решают эту проблему. Вот что делать в Windows 10:

1. Введите environment variables в стартовой строке поиска и откройте Отредактируйте системные переменные среды.

2. Нажмите Переменные среды...

3. В разделе «Системные переменные» найдите переменную с ключом Path и дважды щелкните по ней.

4. Найдите пути, указывающие на файлы python. Скорее всего их нет. Если они есть, выберите и удалите их.

5. Создайте новую переменную, указав путь к исполняемому файлу Python. Обычно это C:\Users\[YOUR USERNAME HERE]\AppData\Local\Programs\Python\Python38. Убедитесь в этом, проверив через проводник.

   Примечание: Если вы не видите AppData, это потому, что у вас нет включен просмотр скрытых элементов: перейдите на вкладку «Вид» и установите флажок «Скрытые элементы».

6. Создайте еще одну переменную, указывающую на каталог Scripts. Обычно это C:\Users\[YOUR USERNAME HERE]\AppData\Local\Programs\Python\Scripts.

7. Перезапустите терминал и попробуйте ввести py, python, python3 или python.exe.

Обходной путь: если вы установили python из exe, выполните следующие шаги.

Шаг 1. Удалите питон.

Шаг 2: Установите python и установите флажок «Путь к Python», как показано на снимке экрана ниже (желтый).

Это решило мою проблему.

Это связано с тем, как Windows Псевдонимы выполнения приложений работает в Git-Bash.

Это известная проблема в MSYS2не удается получить доступ к точкам повторной обработки Windows с помощью IO_REPARSE_TAG_APPEXECLINK.

Как обходной путь, вы можете использовать псевдоним для вызова функции, которая использует cmd.exe под капотом.

Добавьте следующее в ваш файл ~/.bashrc::

function python { cmd.exe /c "python $1 $2 $3";}

Для Python я бы рекомендовал просто отключить псевдонимы выполнения приложений, как в принятом ответе, но для библиотек, которые распространяются исключительно через магазин Windows, например winget, это ваш лучший вариант.

Дальнейшее чтение

• bash: Local/Microsoft/WindowsApps/python3: Отказано в доступе
• Отказано в доступе при запуске из bash
• winget не запускается в WSL2 из-за ошибки формата exeC# 234

Что касается меня, я попробовал manage app execution aliases и получил ошибку, что python3 не является командой, поэтому я использовал py вместо python3, и это сработало.

Я не знаю, почему это происходит, но это сработало для меня.

У меня возникла та же проблема, но в дополнение к тому, что Python был заблокирован, все программы в папке Scripts тоже были заблокированы. Другие ответы о псевдонимах, пути и winpty не помогли.

В конце концов я обнаружил, что это был мой антивирус (Avast), который по какой-то причине решил в одночасье просто заблокировать все скомпилированные скрипты Python по какой-то причине.

К счастью, это легко исправить: просто добавьте в белый список весь каталог Python. См. здесь для полного объяснения.

Добавьте путь к папке python в переменную среды, и она будет работать.

1.ищите переменную окружения

2. Найдите раздел системных переменных и найдите в нем путь к переменной с именем

3. Дважды щелкните путь и добавьте новый путь, который ведет к папке python, и все.

папка python обычно находится в C:\Users["имя пользователя"]\AppData\Local\Programs\Python\Python39

Простой ответ: замените питон на ПЯ и все будет работать как положено.

У меня было это для запуска / выполнения, но не работало

python3 -m http.server 8080

прочитав и попробовав некоторые из приведенных выше решений, они не сработали, у меня сработало

python -m http.server 8080

Для людей, которые приходят к этому вопросу, версия Python желание использовать Microsoft Store и после исправления Связанный «Управление псевдонимами выполнения приложений» от @Зуба, вероятно, произошло и используют Гит для Windows git-bash (также известный как BASH через msys2 mintty), решение, вероятно, просто чтобы не забыть вызвать с помощью winpty.'

winpty python3

Однако, если в системе были другие версии Python, убедитесь, что эти копии были удалены (например, те, что были установлены из python.org) или включены в их конкретное связанное приложение (например, OSGeo4W) (может потребоваться переупорядочивание переменных окружения).

Почему, если winpty забыто, это ошибка разрешения? При первом запуске заглушки Microsoft Store конфликтуют с разрешениями, доступными для msys. Многие другие ответы подробно рассказывают о том, что происходит и почему это кажется странным. Короткий ответ заключается в том, что заглушка пытается быть удобным кратчайшим путем к Магазину Microsoft. Если вы запустите его с помощью winpty, он сможет это сделать. После этого первого раза он по-прежнему нуждается в winpty как по связанным, так и по несвязанным причинам с Microsoft Store.

В Windows 10

• Открыть Панель управления
• Нажмите Система
• Щелкните ссылку Расширенные настройки системы.
• Нажмите кнопку Переменные среды
• В разделе «Системные переменные» найдите переменную среды ДОРОЖКА и выберите ее.
• Нажмите «Изменить» (если переменная среды PATH не существует, нажмите «Создать»).
• В окне Изменить переменную среды укажите значение переменной среды PATH.
• Нажмите ОК
• Закройте все оставшиеся окна, нажав ОК
• Снова откройте окно командной строки и запустите python --version

убедитесь, что C:\Python39\ и C:\Python39\Scripts\ добавлены как к переменным пути системы, так и к переменным пути пользователя.