Ошибка Set-Location : Не удается найти позиционный параметр, принимающий аргумент появляется в PowerShell в тот момент, когда командлет получает больше «свободных» фрагментов текста, чем способен принять: чаще всего виноват путь с пробелами без кавычек, который интерпретатор разбивает на несколько отдельных аргументов. Команда вроде Set-Location C:\Program Files\MyApp воспринимается как два аргумента — C:\Program и Files\MyApp, — а параметр -Path у Set-Location позиционный только один, поэтому второй фрагмент отклоняется с этой ошибкой.
Проблема относится к синтаксису командной строки и не связана с повреждением системы, правами доступа или самим каталогом. Разобраться в том, как PowerShell разбирает аргументы, и исправить команду можно за пару минут — ниже разобраны все типовые причины и способы решения.
Как PowerShell разбирает аргументы и почему возникает ошибка
PowerShell передаёт параметры командлетам по позиции или по имени. У Set-Location первый позиционный параметр — это -Path, и он всего один. Когда вы пишете команду, оболочка сначала разбивает строку на токены по пробелам, и только потом сопоставляет их с параметрами. Любой «лишний» токен, который не начинается с дефиса и не занят именованным параметром, оболочка пытается пристроить на свободную позицию — и если свободных позиций нет, выдаёт именно эту ошибку.
Типичные ситуации, когда позиционный параметр «не находится»:
- 📁 Путь содержит пробелы и не заключён в кавычки:
Set-Location D:\My Documents\Work. - 🔤 В команду случайно попал второй аргумент — например, скопированный вместе с путём фрагмент текста или лишнее слово.
- 🧩 Используется переменная, которая оказалась пустой или содержит несколько строк, и команда получила неожиданный набор значений.
- ✂️ Путь вставлен из буфера обмена вместе с переносом строки, который разорвал команду на две части.
⚠️ Внимание: текст ошибки всегда содержит «лишний» аргумент в кавычках — например, «принимающий аргумент "Files\MyApp"». Этот фрагмент — главная подсказка: именно его PowerShell не смог привязать ни к одному параметру. Начинайте диагностику с поиска этого фрагмента в своей команде.
Решение 1: заключить путь в кавычки
Самый частый случай — пробелы в пути. Достаточно обернуть весь путь в одинарные или двойные кавычки, и PowerShell воспримет его как единый аргумент:
Set-Location "C:\Program Files\MyApp"
Одинарные кавычки ('...') трактуют содержимое буквально, двойные ("...") — допускают подстановку переменных внутри строки. Для обычного перехода по каталогам оба варианта работают одинаково, разница проявляется только при использовании $переменных внутри пути.
Проверить успешность перехода можно командой Get-Location — она выведет текущий каталог. Если переход не выполнился, но ошибки уже нет, вероятно, путь указан с опечаткой: кавычки устраняют ошибку разбора аргументов, но не проверяют существование каталога.
Решение 2: использовать именованный параметр -Path
Явное указание имени параметра делает команду читаемее и исключает двусмысленность при разборе. Синтаксис выглядит так:
Set-Location -Path "D:\Рабочие проекты\Отчёты 2026"
Такой вариант особенно полезен в скриптах, где команду будут читать другие люди или где путь формируется динамически. Именованный параметр однозначно сообщает оболочке, куда отнести аргумент, и снижает риск конфликтов при изменении команды в будущем.
Решение 3: проверить переменные и подстановку путей
Если путь передаётся через переменную, ошибка часто означает, что переменная содержит не то, что ожидалось. Перед вызовом Set-Location выведите её значение:
Write-Host "[$folder]"
Set-Location -Path $folder
Квадратные скобки вокруг значения помогают увидеть скрытые пробелы в начале или конце строки. Если переменная пуста, команда получит не то количество аргументов; если она содержит массив из нескольких строк — Set-Location попытается обработать каждую как отдельный позиционный параметр.
Что проверить при работе с переменными:
- 🔍 Реальное значение переменной через
Write-Hostили$folder | Format-List. - 🧹 Лишние пробелы — их можно убрать методом
$folder.Trim(). - 📦 Тип данных: одна строка или массив (
$folder.GetType()). - 🔗 Корректность склейки путей — безопаснее использовать
Join-Pathвместо ручной конкатенации.
Решение 4: исправить ошибку внутри скрипта
В .ps1-файлах ошибка нередко возникает из-за того, что команда разорвана переносом строки или после пути следует ещё одна команда, написанная без разделителя. PowerShell допускает продолжение команды на следующей строке только в определённых местах — например, после символа конвейера | или обратного апострофа `. Случайный перенос посередине пути превращает вторую половину в отдельный «аргумент».
Откройте скрипт в редакторе с подсветкой синтаксиса (например, PowerShell ISE или VS Code с расширением PowerShell) и проверьте строку, номер которой указан в сообщении об ошибке. Подсветка сразу покажет, где заканчивается строка в кавычках и не «выпал» ли фрагмент наружу.
☑️ Диагностика ошибки Set-Location
Таблица: типовые причины и способы устранения
| Симптом в команде | Причина | Решение |
|---|---|---|
| Путь с пробелами без кавычек | Разбивка на несколько токенов | Обернуть путь в кавычки |
| Лишнее слово после пути | Второй позиционный аргумент | Удалить лишний фрагмент |
| Переменная вместо пути | Пустое значение или массив | Проверить содержимое, привести к строке |
| Ошибка в .ps1-файле | Разрыв команды переносом строки | Объединить строку или исправить перенос |
| Путь из буфера обмена | Скрытые символы, переносы | Вставить в редактор и очистить |
Специальные символы в путях
Помимо пробелов, сложности создают квадратные скобки [ ] в именах папок: PowerShell трактует их как символы подстановки (wildcard). В таком случае используйте параметр -LiteralPath, который отключает обработку масок:
Set-Location -LiteralPath "D:\Backup [old]\2026"
Обратный апостроф ` в имени каталога внутри двойных кавычек воспринимается как escape-символ — здесь помогут одинарные кавычки. Эти нюансы редки, но именно они становятся причиной «необъяснимых» ошибок в путях, которые выглядят совершенно корректно.
Почему cd выдаёт ту же ошибку
cd — это псевдоним (alias) командлета Set-Location, поэтому синтаксис и ошибки у них полностью идентичны. Все решения из статьи применимы и к cd: cd "C:\Program Files". Проверить привязку псевдонима можно командой Get-Alias cd.
⚠️ Внимание: не пытайтесь «обойти» проблему, экранируя пробелы обратным апострофом (`) в каждом месте пути — это работает, но делает команду нечитаемой и хрупкой. Кавычки или-LiteralPath— правильное и устойчивое решение.
Профилактика: как писать команды без ошибок
Выработайте привычку всегда заключать пути в кавычки, даже если пробелов в них сейчас нет — при переносе скрипта на другую машину или переименовании папки команда не сломается. В скриптах дополнительно используйте Test-Path перед переходом, чтобы отличать синтаксическую ошибку от несуществующего каталога:
if (Test-Path -LiteralPath $folder) { Set-Location -LiteralPath $folder }
Ещё один удобный приём — автодополнение клавишей Tab: PowerShell сам подставит путь и автоматически добавит кавычки, если они нужны. Это исключает опечатки и проблемы с пробелами одновременно.
Частые вопросы
Почему команда работает в консоли, но падает в скрипте?
В скрипте путь обычно приходит из переменной или формируется склейкой строк, а значение может содержать пробелы, переносы строк или оказаться пустым. Выведите значение через Write-Host перед вызовом и сравните с тем, что вы вводили вручную.
Чем отличаются -Path и -LiteralPath у Set-Location?
-Path обрабатывает символы подстановки (*, ?, [ ]) как маски, а -LiteralPath воспринимает строку буквально. Для путей с квадратными скобками в имени используйте -LiteralPath.
Можно ли использовать прямые косые черты вместо обратных?
Да, PowerShell в большинстве случаев принимает пути вида C:/Program Files/MyApp, но пробелы всё равно требуют кавычек. На поведение разбора аргументов тип слэша не влияет.
Ошибка указывает аргумент, которого нет в моей команде. Откуда он взялся?
Скорее всего, фрагмент пришёл из переменной, из буфера обмена вместе со скрытым символом или из соседней строки скрипта, слившейся с текущей из-за отсутствия разделителя. Проверьте команду посимвольно в редакторе с подсветкой синтаксиса.
Работают ли эти решения в Windows PowerShell 5.1 и PowerShell 7?
Да, правила разбора аргументов и синтаксис Set-Location в обеих версиях одинаковы, поэтому кавычки, -Path и -LiteralPath работают независимо от версии оболочки.