Как исправить The term is not recognized as the name of a cmdlet

Сообщение об ошибке «The term is not recognized as the name of a cmdlet» на экране PowerShell

Почему это важно: эта ошибка блокирует выполнение скриптов и усложняет обслуживание серверов и автоматизацию на нескольких машинах.

Краткое объяснение термина

Cmdlet — небольшая команда в PowerShell, реализованная в .NET; обычно вызывается как одно слово, например Get-Process.
Dot-sourcing — способ запустить скрипт в текущем сеансе PowerShell, а не в отдельном процессе; записывается как . + путь.

Основные причины ошибки

Вызов модуля или cmdlet, который не установлен или не загружен.
Синтаксические или орфографические ошибки в скрипте/имени команды.
Неправильный путь к скрипту или проблемы с переменной окружения PATH.
Политика исполнения (ExecutionPolicy) блокирует запуск локальных скриптов.

Быстрые проверки перед правкой

Проверьте точное сообщение об ошибке — оно часто содержит имя отсутствующей команды.
Попробуйте выполнить Get-Command -Name <имя_команды> чтобы увидеть, доступна ли команда.
Посмотрите переменную пути: echo $env:Path.
Узнайте политику исполнения: Get-ExecutionPolicy.

1. Запуск скрипта: используйте правильную запись пути

Откройте PowerShell или другую командную строку.
Для запуска локального скрипта используйте точку и обратную косую черту: .\myscript.ps1 — правильный пример: .\myscript.ps1. Пример (введите в PowerShell): ``` .\myscript.ps1 ``` > Important: Частая ошибка — вводmyscript.ps1без.и`. В таком случае PowerShell может попытаться найти команду в PATH, а не локальный файл.

$Пример ввода команды .\myscript.ps1 в PowerShell$

2. Убедитесь, что модуль установлен и доступен

Если ошибка указывает на конкретный термин/командлет, выясните, к какому модулю он принадлежит.
Выполните:

Get-Module -Name YourModuleName -ListAvailable

Если модуль не найден, установите его (например, из PSGallery) и загрузите:

Install-Module -Name YourModuleName -Scope CurrentUser
Import-Module YourModuleName

Проверьте наличие команд в модуле:

Get-Command -Module YourModuleName

Вывод Get-Module -ListAvailable с установленным модулем

3. Проверка синтаксиса и пропущенных кавычек

Откройте файл скрипта в редакторе.
Ищите незакрытые кавычки, скобки, опечатки в именах функций и переменных.
Запустите powershell -NoProfile -Command { .\myscript.ps1 } чтобы увидеть минимально возможное окружение и сократить влияние профиля.

4. Политика исполнения и разрешения

Узнать текущую политику: Get-ExecutionPolicy -List.
Для разработки можно временно разрешить выполнение локальных скриптов:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

Важно: изменяйте политику исполнения с пониманием рисков безопасности.

Диаграмма принятия решений (быстрая навигация)

flowchart TD
  A[Ошибка: термин не распознан] --> B{Сообщение указывает имя?}
  B -- Да --> C[Get-Command -Name <имя>]
  C --> D{Команда найдена?}
  D -- Да --> E[Импортировать модуль: Import-Module]
  D -- Нет --> F[Проверить PATH и путь к скрипту]
  B -- Нет --> F
  F --> G{Файл локальный?}
  G -- Да --> H[Запустить .\\script.ps1]
  G -- Нет --> I[Установить/установить модуль или пакет]
  I --> J[Проверить ExecutionPolicy и права]
  H --> J
  E --> K[Проверить синтаксис и кавычки]
  K --> L[Повторно запустить и проверить]

Дополнительные рекомендации и альтернативные подходы

Если скрипт вызывается из планировщика задач или CI, убедитесь, что учётная запись имеет те же пути и модули.
Для переносимых сценариев используйте явные импорты модулей в начале скрипта: Import-Module -Name RequiredModule -ErrorAction Stop.
Для тестирования окружения запускайте PowerShell с флагом -NoProfile, чтобы исключить влияние пользовательских профилей.

Рольный чек-лист (администратор / разработчик)

Администратор:
- Проверил установленные модули на всех серверах.
- Синхронизировал PATH и ExecutionPolicy на целевых машинах.
- Обновил документацию и автозагрузку модулей.
Разработчик:
- Добавил проверки Get-Command и обработку ошибок в скрипт.
- Использует Import-Module в начале скрипта.
- Протестировал запуск на чистой сессии с -NoProfile.

Критерии приёмки

Скрипт запускается без ошибки в целевом окружении.
Все используемые командлеты доступны (Get-Command подтверждает).
Политика исполнения и права не препятствуют выполнению.

Когда этот метод не помогает (контрпример)

Если проблема вызвана повреждённой установкой PowerShell или конфликтом версий, простая установка модуля не устранит причину — потребуется переустановка или откат версии PowerShell.
Если имя команды совпадает с исполняемым файлом в PATH с другим поведением, потребуется переименование или явное указание пути.

Быстрый чек-лист для устранения ошибки

[ ] Ввести Get-Command -Name
[ ] Проверить Get-Module -ListAvailable
[ ] Запустить .\script.ps1 из правильной директории
[ ] Проверить Get-ExecutionPolicy -List
[ ] Импортировать модуль: Import-Module или установить через Install-Module

1‑строчная глоссарий

Cmdlet: встроенная команда PowerShell.
Dot-sourcing: запуск скрипта в текущем сеансе через . перед путём.
ExecutionPolicy: настройка безопасности, ограничивающая выполнение скриптов.

Итог и рекомендации

Ошибка «The term is not recognized as the name of a cmdlet» решается системным подходом: проверьте доступность команды через Get-Command, убедитесь, что модуль установлен (Get-Module -ListAvailable / Install-Module), запустите скрипт с правильным указанием пути (.\script.ps1), и при необходимости настройте ExecutionPolicy. Для продакшен-сред соблюдайте безопасность при изменении политик и документируйте изменения.

Если вы решили проблему самостоятельно — опишите своё решение в комментариях: это поможет коллегам быстрее диагностировать похожие ошибки.