-ArgumentList
se basa en el uso con ScriptBlock comandos, como:
Invoke-Command -Cn (gc Servers.txt) {param($Debug=$False, $Clear=$False) C:\Scripts\ArchiveEventLogs\ver5\ArchiveEventLogs.ps1 } -ArgumentList $False,$True
Cuando se llama con un -File
todavía pasa los parámetros como una matriz Splatted mudo. He enviado un feature request para agregarlo al comando (vote eso).
lo tanto, usted tiene dos opciones:
Si usted tiene un script que se veía así, en una ubicación de red accesible desde la máquina remota (Tenga en cuenta que -Debug
está implícito, porque cuando se utiliza el atributo Parameter
, el guión CmdletBinding obtiene de forma implícita, y por lo tanto, todos los parámetros comunes):
param(
[Parameter(Position=0)]
$one
,
[Parameter(Position=1)]
$two
,
[Parameter()]
[Switch]$Clear
)
"The test is for '$one' and '$two' ... and we $(if($DebugPreference -ne 'SilentlyContinue'){"will"}else{"won't"}) run in debug mode, and we $(if($Clear){"will"}else{"won't"}) clear the logs after."
sin quedar atrapado en el significado de $Clear
... si quería invocar que se puede utilizar cualquiera de los siguientes Invoke-Command
sintaxis:
icm -cn (gc Servers.txt) {
param($one,$two,$Debug=$False,$Clear=$False)
C:\Scripts\ArchiveEventLogs\ver5\ArchiveEventLogs.ps1 @PSBoundParameters
} -ArgumentList "uno", "dos", $false, $true
En ese uno, soy la duplicación de todos los parámetros que me importa en el ScriptBlock para que pueda pasar valores. Si puedo codificarlos (que es lo que realmente hice), no hay necesidad de hacer eso y usar PSBoundParameters
, puedo pasar los que necesito. En el segundo ejemplo a continuación voy a pasar el $ Borrar uno, sólo para demostrar cómo pasar los parámetros del conmutador:
icm -cn $Env:ComputerName {
param([bool]$Clear)
C:\Scripts\ArchiveEventLogs\ver5\ArchiveEventLogs.ps1 "uno" "dos" -Debug -Clear:$Clear
} -ArgumentList $(Test-Path $Profile)
La otra opción
Si el guión es en su máquina local, y usted no desea cambiar los parámetros para que sean posicionales, o si desea especificar parámetros que son parámetros comunes (para que no pueda controlarlos), querrá obtener el contenido de ese script e incrustarlo en su scriptblock:
$script = [scriptblock]::create(@"
param(`$one,`$two,`$Debug=`$False,`$Clear=`$False)
&{ $(Get-Content C:\Scripts\ArchiveEventLogs\ver5\ArchiveEventLogs.ps1 -delimiter ([char]0)) } @PSBoundParameters
"@)
Invoke-Command -Script $script -Args "uno", "dos", $false, $true
PostScript:
Si realmente necesita pasar una variable para el nombre del script, lo que haría dependerá de si la variable se define localmente o de forma remota. En general, si usted tiene una variable $Script
o una variable de entorno $Env:Script
con el nombre de un guión, puede ejecutarlo con el operador de llamada (&): &$Script
o &$Env:Script
Si se trata de una variable de entorno que ya está definido en el computadora remota, eso es todo.Si se trata de una variable locales, entonces tendrá que pasar al bloque de secuencia de comandos remota:
Invoke-Command -cn $Env:ComputerName {
param([String]$Script, [bool]$Clear)
&$Script "uno" "dos" -Debug -Clear:$Clear
} -ArgumentList $ScriptPath, $(Test-Path $Profile)
ArgumentList está disponible con -FilePath además. Invoke-Command [-FilePath] [[-Sesión] ] [-AsJob] [-HideComputerName] [-JobName ] [-T hrottleLimit ] [-ArgumentList
Sí ravikanth, pero parece que ArgumentList está splatting a la secuencia de comandos, por lo que no puede especificar los parámetros * named *? – Jaykul
Es una pena que StackOverflow no comprenda el script de PowerShell ... el resaltado de sintaxis de los nombres del script deja mucho que desear. – Jaykul