tl; dr:
Как правило, не используйте Invoke-Command
для локальные вызовы - хотя это технически возможно, есть только один конкретный вариант использования, для которого это требуется (см. ниже).
Вместо этого вызывайте скрипты напрямую:
.\getprocess.ps1
Примечание. В отличие от cmd.exe
, PowerShell по своей конструкции требует .\
для выполнения исполняемого файла, расположенного в текущем каталоге. То есть, чтобы избежать случайного выполнения исполняемых файлов в текущем каталоге, а не из каталога, указанного в $env:Path
, PowerShell в качестве функции безопасности требует, чтобы вы явным образом сигнализировали о намерении выполнить что-то в текущем каталоге (.
). Sup >
Для блоков скриптов ({ ... }
), используйте &
, вызвать оператора (например, & { Get-Date }
).
Исключительно по синтаксическим причинам вам ситуативно также потребуется &
для путей к файлам сценария, если они указаны как путь в кавычках (например, & '.\getprocess.ps1'
) и / или если путь включает ссылки на переменные (например,
& $HOME\getprocess.ps1
).
(Отдельно .
, оператор поиска точки необходим в обоих случаях, чтобы выполнить скрипт [блок] непосредственно в области действия вызывающего объекта, а не в дочерней области) .
Обратите внимание, что технически вы можете объединить передачу блока сценария в Invoke-Command
(параметр -ScriptBlock
) с вызовом локального сценария:
# The script block positionally binds to the -ScriptBlock parameter.
# This is essentially the more expensive equivalent of:
# & .\getprocess.ps1
Invoke-Command { .\getprocess.ps1 }
Это медленнее и не дает преимуществ перед прямым вызовом. Однако есть один возможный вариант использования:
Если сценарий не является расширенный скрипт, и вы хотели воспользоваться Invoke-Command
потоковым сбором вывода общие параметры, такие как -ErrorVariable
(если вызываемый скрипт или функция является расширенным, он поддерживает эти общие параметры сам).
# Invoke locally and collect errors in $errs
Invoke-Command { .\getprocess.ps1 } -ErrorVariable errs
Предупреждение: по крайней мере, начиная с PowerShell 7.2, Invoke-Command
не применяет общий параметр -ErrorAction
для ошибок, возникающих в блоке скрипта, поэтому его нельзя использовать для управления обработка ошибок; например, -ErrorAction Stop
не влияет на команды в блоке скрипта.
Что касается того, что вы пробовали:
Действительно, как вы указываете в своем собственном ответе, -FilePath
должен сочетаться с параметр
-ComputerName
(прискорбно, что сообщение об ошибке носит столь общий характер).
Назначение параметра -FilePath
- скопировать содержимое локального скрипта (*.ps1
файл) на удаленный компьютер для выполнения там. То есть это удобный механизм выполнения кода сценария, доступного (только) локально на удаленной машине.
Хотя технически вы можете настроить таргетинг на локальный компьютер через -ComputerName localhost
(или, более кратко, через -ComputerName .
/ -cn .
), это не равнозначно локальному вызову :
Каждый раз, когда указан -ComputerName
- даже с -ComputerName localhost
- используется инфраструктура удаленного взаимодействия PowerShell, что имеет серьезные последствия:
Целевой компьютер - даже если он локальный - должен быть настроен для удаленного взаимодействия PowerShell - см. about_Remote_Requirements.
Если вы нацеливаетесь конкретно на локальный компьютер, вы должны работать в сеансе с повышенными правами (под управлением администратора).
Выполнение будет намного медленнее, чем прямой (локальный) вызов.
Точность типов может быть потеряна как для входных, так и для выходных данных, учитывая, что задействовано межпроцессное маршалинг через инфраструктуру сериализации PowerShell на основе XML - см. это ответ.
Тем не менее, если намерение состоит в том, чтобы локально протестировать удаленное выполнение вашего скрипта и ваш локальный компьютер настроен как цель удаленного взаимодействия, тогда используйте -ComputerName localhost
(-ComputerName .
/ -cn .
) имеет смысл, учитывая, что в этом случае инфраструктура удаленного взаимодействия PowerShell задействуется так же, как и при действительно удаленном вызове.
Обратите внимание, однако, что такие вызовы удаленного взаимодействия с обратной связью требуют повышения прав (выполняются от имени администратора).
person
mklement0
schedule
01.04.2020