Ошибка Имя "app" не распознано как имя командлета... команда не найдена, однако существует в текущем расположении появляется в PowerShell, когда исполняемый файл лежит в текущей папке, но оболочка отказывается запускать его без явного указания пути. Это не сбой системы, а штатное защитное поведение: PowerShell специально не ищет программы в текущем каталоге, чтобы случайно не выполнить вредоносный файл с именем популярной команды.
В классической командной строке cmd.exe такой команды достаточно — она ищет исполняемые файлы сначала в текущей папке. PowerShell устроен иначе, и именно это различие чаще всего сбивает с толку пользователей, переходящих с cmd или копирующих инструкции из старых руководств. Разберёмся, почему возникает сообщение и как правильно запустить нужную программу.
Почему PowerShell не видит команду в текущей папке
При вводе команды оболочка ищет её в строго определённом порядке: сначала среди встроенных командлетов и алиасов, затем среди функций, а потом — по каталогам, перечисленным в переменной окружения PATH. Текущая рабочая папка в этот список по умолчанию не входит.
Такое решение принято осознанно. Представьте: вы скачали архив, распаковали его, зашли в папку и ввели привычную команду. Если бы PowerShell искал в текущем каталоге первым делом, злоумышленник мог бы подложить туда вредоносный ping.exe или ipconfig.exe, который запустился бы вместо системной утилиты. PowerShell требует явно указать путь к файлу в текущем каталоге — это защита, а не ограничение.
Само сообщение об ошибке об этом прямо сообщает: оболочка обнаружила файл и подсказывает добавить .\ перед именем, если вы действительно хотите запустить именно его.
Быстрое решение: запуск через .\
Самый простой способ выполнить программу из текущего расположения — добавить префикс .\ перед именем файла. Точка означает «текущий каталог», а обратный слэш отделяет путь от имени.
.\app.exe
.\script.ps1
.\program --help
Если в имени файла или пути есть пробелы, потребуется оператор вызова & и кавычки:
& ".\my app.exe"Проверить, какой именно файл будет запущен, помогает команда Get-Command:
Get-Command .\app.exe- 🔍
.\app.exe— запуск исполняемого файла из текущей папки; - 📄
.\script.ps1— запуск скрипта PowerShell (см. раздел про политику выполнения); - 🛠️
& ".\имя с пробелами.exe"— вызов файла с пробелами в имени; - ✅
Get-Command .\file— проверка, какой файл реально будет выполнен.
Альтернатива: добавление папки в PATH
Если программу приходится запускать регулярно, удобнее добавить её каталог в переменную PATH. Тогда команда будет доступна из любого расположения без префикса .\.
Временное добавление, действующее только в текущем сеансе PowerShell:
$env:Path += ";C:\Tools\MyApp"Постоянное изменение выполняется через Параметры Windows → Система → О системе → Дополнительные параметры системы → Переменные среды. Там нужно выбрать переменную Path (пользовательскую или системную) и добавить путь к папке. После сохранения откройте новое окно терминала — в уже запущенных сеансах изменения не подхватятся.
⚠️ Внимание: добавляйте в PATH только те каталоги, содержимому которых доверяете. Папка, куда могут писать другие программы или пользователи, — потенциальный вектор подмены исполняемых файлов.
Сравнение способов запуска
| Способ | Когда применять | Действие |
|---|---|---|
.\app.exe | Разовый запуск из текущей папки | Не требует настройки |
| Полный путь к файлу | Файл в другом каталоге | Указать путь явно |
| Добавление в PATH | Постоянное использование | Настройка переменных среды |
cmd /c app.exe | Совместимость со старыми инструкциями | Запуск через cmd из PowerShell |
Выбор зависит от сценария. Для одноразовой проверки достаточно префикса .\; для инструментов, которыми пользуетесь ежедневно, рациональнее один раз настроить PATH.
Ошибка при запуске скриптов .ps1: политика выполнения
Отдельный случай — когда .\script.ps1 вводится правильно, но PowerShell выдаёт ошибку о запрете выполнения сценариев. Здесь работает другой механизм защиты — политика выполнения (Execution Policy), которая по умолчанию в клиентских версиях Windows блокирует запуск скриптов.
Узнать текущее значение можно командой:
Get-ExecutionPolicyТипичные значения и их смысл:
- 🔒
Restricted— скрипты не выполняются вообще (значение по умолчанию); - 📦
RemoteSigned— локальные скрипты работают, скачанные из интернета требуют цифровой подписи; - 🌐
Unrestricted— выполняются любые скрипты, с предупреждением для скачанных; - ⏭️
Bypass— ничего не блокируется и не спрашивается.
Для разового запуска не обязательно менять политику глобально — можно обойти её в пределах одного сеанса:
powershell -ExecutionPolicy Bypass -File .\script.ps1⚠️ Внимание: не понижайте политику выполнения на постоянной основе без необходимости. РежимRemoteSignedдля текущего пользователя — разумный компромисс:Set-ExecutionPolicy RemoteSigned -Scope CurrentUser. Перед запуском любого скачанного скрипта откройте его в текстовом редакторе и убедитесь, что понимаете, что он делает.
☑️ Диагностика ошибки «команда не найдена»
Когда файл есть, но не запускается: другие причины
Иногда префикс .\ не помогает, и ошибка сохраняется либо меняется на другую. Возможные причины стоит проверять последовательно.
Первая — расширение файла. PowerShell выполняет только типы, перечисленные в переменной $env:PATHEXT (обычно это .exe, .bat, .cmd, .ps1 и некоторые другие). Файл без расширения или с нестандартным расширением не запустится как программа, даже если лежит в PATH.
Вторая возможная причина — скрытое расширение. Проводник Windows по умолчанию не показывает расширения, и файл app.exe.txt может отображаться как app.exe. Проверьте реальное имя через Get-ChildItem в PowerShell — терминал показывает имена полностью.
Третья — блокировка файла, скачанного из интернета. Windows помечает такие файлы, и в свойствах файла (правый клик → Свойства) может присутствовать кнопка разблокировки. Для скриптов аналогичный эффект даёт команда Unblock-File .\script.ps1.
Как узнать, откуда PowerShell берёт команду
Выполните Get-Command имя_команды — в выводе будет поле Source с полным путём к файлу. Если команда не найдена вообще, проверьте вывод $env:Path -split ";" — так видно все каталоги, которые оболочка просматривает при поиске.
Запуск из Windows Terminal и VS Code
Описанное поведение одинаково в классической консоли PowerShell, в Windows Terminal и во встроенном терминале Visual Studio Code — везде, где работает PowerShell, действует то же правило с префиксом .\. Различие лишь в том, что в VS Code терминал может открываться в папке проекта, и относительные пути будут отсчитываться именно от неё.
Если инструкция из интернета написана для cmd и команда «не находится», почти всегда достаточно добавить .\ или переключить профиль терминала на Command Prompt. В Windows Terminal это делается через стрелку рядом с кнопкой новой вкладки.
Частые вопросы
Почему в cmd команда работает, а в PowerShell — нет?
Командная строка cmd.exe ищет исполняемые файлы в текущем каталоге в первую очередь. PowerShell сознательно отказался от этого поведения ради безопасности, поэтому требует явного пути: .\program.exe.
Можно ли заставить PowerShell искать в текущей папке, как cmd?
Технически можно добавить точку (.) в переменную PATH, но делать этого не стоит: вы вернёте уязвимость, от которой PowerShell защищает. Любой вредоносный файл с именем популярной команды в текущей папке сможет подменить системную утилиту.
Добавил .\, но скрипт .ps1 всё равно не запускается. Что делать?
Вероятно, срабатывает политика выполнения. Проверьте её командой Get-ExecutionPolicy. Для разового запуска используйте powershell -ExecutionPolicy Bypass -File .\script.ps1 или установите RemoteSigned для текущего пользователя.
Команда работает в одной папке, но не работает в другой. Почему?
Значит, исполняемый файл лежит только в первой папке, а её путь не добавлен в PATH. Либо переходите в нужный каталог и используйте .\, либо добавьте папку с программой в переменные среды, чтобы команда была доступна отовсюду.
Как проверить, какой именно файл запустится по команде?
Выполните Get-Command имя — в выводе поле Source покажет полный путь к файлу, который PowerShell выберет при запуске. Это удобно, когда в системе установлено несколько версий одной программы.