Wait-Job
Supprime l’invite de commandes jusqu’à ce que l’un ou l’ensemble des travaux en arrière-plan PowerShell exécutés dans la session soient terminés.
Syntaxe
Wait-Job
[-Any]
[-Timeout <Int32>]
[-Force]
[-Id] <Int32[]>
[<CommonParameters>]
Wait-Job
[-Job] <Job[]>
[-Any]
[-Timeout <Int32>]
[-Force]
[<CommonParameters>]
Wait-Job
[-Any]
[-Timeout <Int32>]
[-Force]
[-Name] <String[]>
[<CommonParameters>]
Wait-Job
[-Any]
[-Timeout <Int32>]
[-Force]
[-InstanceId] <Guid[]>
[<CommonParameters>]
Wait-Job
[-Any]
[-Timeout <Int32>]
[-Force]
[-State] <JobState>
[<CommonParameters>]
Wait-Job
[-Any]
[-Timeout <Int32>]
[-Force]
[-Filter] <Hashtable>
[<CommonParameters>]
Description
L’applet de commande Wait-Job
attend que les travaux en arrière-plan PowerShell se terminent avant d’afficher l’invite de commandes. Vous pouvez attendre la fin de tout travail en arrière-plan ou jusqu’à ce que tous les travaux en arrière-plan soient terminés, et vous pouvez définir un délai d’attente maximal pour le travail.
Lorsque les commandes du travail sont terminées, Wait-Job
affiche l’invite de commandes et retourne un objet de travail pour pouvoir le diriger vers une autre commande.
Vous pouvez utiliser Wait-Job
cmdlet pour attendre les travaux en arrière-plan, tels que ceux qui ont été démarrés à l’aide de l’applet de commande Start-Job
ou du paramètre AsJob de l’applet de commande Invoke-Command
. Pour plus d’informations sur les travaux en arrière-plan Windows PowerShell, consultez about_Jobs.
À compter de Windows PowerShell 3.0, l’applet de commande Wait-Job
attend également les types de travaux personnalisés, tels que les travaux de flux de travail et les instances de travaux planifiés. Pour permettre à Wait-Job
d’attendre des travaux d’un type particulier, importez le module qui prend en charge le type de travail personnalisé dans la session avant d’exécuter l’applet de commande Get-Job
, soit à l’aide de l’applet de commande Import-Module
, soit en utilisant ou en obtenant une applet de commande dans le module. Pour plus d’informations sur un type de travail personnalisé particulier, consultez la documentation de la fonctionnalité de type de travail personnalisé.
Exemples
Exemple 1 : Attendre tous les travaux
Get-Job | Wait-Job
Cette commande attend que tous les travaux en arrière-plan s’exécutant dans la session se terminent.
Exemple 2 : Attendre que les travaux démarrent sur des ordinateurs distants à l’aide de Start-Job
$s = New-PSSession Server01, Server02, Server03
Invoke-Command -Session $s -ScriptBlock {Start-Job -Name Date1 -ScriptBlock {Get-Date}}
$done = Invoke-Command -Session $s -Command {Wait-Job -Name Date1}
$done.Count
3
Cet exemple montre comment utiliser l’applet de commande Wait-Job
avec les travaux démarrés sur des ordinateurs distants à l’aide de l’applet de commande Start-Job
. Les commandes Start-Job
et Wait-Job
sont envoyées à l’ordinateur distant à l’aide de l’applet de commande Invoke-Command
.
Cet exemple utilise Wait-Job
pour déterminer si une commande Get-Date
exécutée en tant que travail en arrière-plan sur trois ordinateurs différents est terminée.
La première commande crée une session Windows PowerShell (PSSession) sur chacun des trois ordinateurs distants et les stocke dans la variable $s
.
La deuxième commande utilise Invoke-Command
pour exécuter Start-Job
dans chacune des trois sessions de $s
.
Tous les travaux sont nommés Date1.
La troisième commande utilise Invoke-Command
pour exécuter Wait-Job
. Cette commande attend que les travaux Date1 sur chaque ordinateur se terminent. Il stocke la collection obtenue (tableau) d’objets de travail dans la variable $done
.
La quatrième commande utilise la propriété Count du tableau d’objets de travail dans la variable $done
pour déterminer le nombre de travaux terminés.
Exemple 3 : Déterminer quand le premier travail en arrière-plan se termine
$s = New-PSSession (Get-Content Machines.txt)
$c = 'Get-EventLog -LogName System | where {$_.EntryType -eq "error" --and $_.Source -eq "LSASRV"} | Out-File Errors.txt'
Invoke-Command -Session $s -ScriptBlock {Start-Job -ScriptBlock {$Using:c}
Invoke-Command -Session $s -ScriptBlock {Wait-Job -Any}
Cet exemple utilise le paramètre Any de Wait-Job
pour déterminer quand le premier de nombreux travaux en arrière-plan exécutés dans la session active est terminé. Il montre également comment utiliser l’applet de commande Wait-Job
pour attendre que les travaux distants se terminent.
La première commande crée un PSSession Get-Content
pour obtenir le contenu du fichier. La commande Get-Content
est placée entre parenthèses pour vous assurer qu’elle s’exécute avant la commande New-PSSession
.
La deuxième commande stocke une chaîne de commande Get-EventLog
, entre guillemets, dans la variable $c
.
La troisième commande utilise Invoke-Command
cmdlet pour exécuter Start-Job
dans chacune des sessions de $s
.
La commande Start-Job
démarre un travail en arrière-plan qui exécute la commande Get-EventLog
dans la variable $c
.
La commande utilise la Using scope modificateur pour indiquer que la variable $c
a été définie sur l’ordinateur local. Le modificateur d’étendue Using est introduit dans Windows PowerShell 3.0. Pour plus d’informations sur le modificateur d’étendue Using, consultez about_Remote_Variables.
La quatrième commande utilise Invoke-Command
pour exécuter une commande Wait-Job
dans les sessions. Il utilise le paramètre Any pour attendre que le premier travail sur les ordinateurs distants soit terminé.
Exemple 4 : Définir un temps d’attente pour les travaux sur des ordinateurs distants
$s = New-PSSession Server01, Server02, Server03
$jobs = Invoke-Command -Session $s -ScriptBlock {Start-Job -ScriptBlock {Get-Date}}
$done = Invoke-Command -Session $s -ScriptBlock {Wait-Job -Timeout 30}
Cet exemple montre comment utiliser le paramètre Timeout de Wait-Job
pour définir un délai d’attente maximal pour les travaux exécutés sur des ordinateurs distants.
La première commande crée une psSession sur chacun des trois ordinateurs distants (Server01, Server02 et Server03), puis stocke les objets PSSession dans la variable $s
.
La deuxième commande utilise Invoke-Command
pour exécuter Start-Job
dans chacun des objets PSSession dans $s
. Il stocke les objets de travail résultants dans la variable $jobs
.
La troisième commande utilise Invoke-Command
pour exécuter Wait-Job
dans chacune des sessions de $s
. La commande Wait-Job
détermine si toutes les commandes ont été effectuées dans les 30 secondes. Il utilise le paramètre Timeout avec la valeur 30 pour établir le délai d’attente maximal, puis stocke les résultats de la commande dans la variable $done
.
Dans ce cas, après 30 secondes, seule la commande sur l’ordinateur Server02 est terminée.
Wait-Job
termine l’attente, affiche l’invite de commandes et retourne l’objet qui représente le travail terminé.
La variable $done
contient un objet de travail qui représente le travail exécuté sur Server02.
Exemple 5 : Patientez jusqu’à la fin de l’un de plusieurs travaux
Wait-Job -id 1,2,5 -Any
Cette commande identifie trois travaux par leurs ID et attend que l’un d’eux soit terminé. L’invite de commandes retourne une fois le premier travail terminé.
Exemple 6 : Attendre une période, puis autoriser le travail à continuer en arrière-plan
Wait-Job -Name "DailyLog" -Timeout 120
Cette commande attend 120 secondes (deux minutes) pour que la tâche DailyLog se termine. Si le travail ne se termine pas au cours des deux prochaines minutes, l’invite de commandes retourne de toute façon et le travail continue à s’exécuter en arrière-plan.
Exemple 7 : Attendre un travail par nom
Wait-Job -Name "Job3"
Cette commande utilise le nom du travail pour identifier le travail pour lequel attendre.
Exemple 8 : Attendre les travaux sur l’ordinateur local démarré avec Start-Job
$j = Start-Job -ScriptBlock {Get-ChildItem *.ps1| where {$_lastwritetime -gt ((Get-Date) - (New-TimeSpan -Days 7))}}
$j | Wait-Job
Cet exemple montre comment utiliser l’applet de commande Wait-Job
avec des travaux démarrés sur l’ordinateur local à l’aide de Start-Job
.
Ces commandes démarrent un travail qui obtient les fichiers de script Windows PowerShell qui ont été ajoutés ou mis à jour la semaine dernière.
La première commande utilise Start-Job
pour démarrer un travail en arrière-plan sur l’ordinateur local. Le travail exécute une commande Get-ChildItem
qui obtient tous les fichiers qui ont une extension de nom de fichier .ps1 qui ont été ajoutés ou mis à jour la semaine dernière.
La troisième commande utilise Wait-Job
attendre que le travail soit terminé. Une fois le travail terminé, la commande affiche l’objet de travail, qui contient des informations sur le travail.
Exemple 9 : Attendre que les travaux démarrent sur des ordinateurs distants à l’aide de Invoke-Command
$s = New-PSSession Server01, Server02, Server03
$j = Invoke-Command -Session $s -ScriptBlock {Get-Process} -AsJob
$j | Wait-Job
Cet exemple montre comment utiliser Wait-Job
avec les travaux démarrés sur des ordinateurs distants à l’aide du paramètre AsJob de Invoke-Command
. Lorsque vous utilisez AsJob, le travail est créé sur l’ordinateur local et les résultats sont automatiquement retournés à l’ordinateur local, même si le travail s’exécute sur les ordinateurs distants.
Cet exemple utilise Wait-Job
pour déterminer si une commande Get-Process
en cours d’exécution dans les sessions sur trois ordinateurs distants est terminée.
La première commande crée objets PSSession sur trois ordinateurs et les stocke dans la variable $s
.
La deuxième commande utilise Invoke-Command
pour exécuter Get-Process
dans chacune des trois sessions de $s
.
La commande utilise le paramètre AsJob pour exécuter la commande de manière asynchrone en tant que travail en arrière-plan. La commande retourne un objet de travail, tout comme les travaux démarrés à l’aide de Start-Job
, et l’objet de travail est stocké dans la variable $j
.
La troisième commande utilise un opérateur de pipeline (|
) pour envoyer l’objet de travail dans $j
à l’applet de commande Wait-Job
. Une commande Invoke-Command
n’est pas nécessaire dans ce cas, car le travail réside sur l’ordinateur local.
Exemple 10 : Attendre un travail qui a un ID
Get-Job
Id Name State HasMoreData Location Command
-- ---- ----- ----------- -------- -------
1 Job1 Completed True localhost,Server01.. get-service
4 Job4 Completed True localhost dir | where
Wait-Job -Id 1
Cette commande attend la tâche avec une valeur d’ID de 1.
Paramètres
-Any
Indique que cette applet de commande affiche l’invite de commandes et retourne l’objet de travail, à la fin d’un travail. Par défaut, Wait-Job
attend que tous les travaux spécifiés soient terminés avant d’afficher l’invite.
Type: | SwitchParameter |
Position: | Named |
Valeur par défaut: | None |
Obligatoire: | False |
Accepter l'entrée de pipeline: | False |
Accepter les caractères génériques: | False |
-Filter
Spécifie une table de conditions de hachage. Cette applet de commande attend les travaux qui répondent à toutes les conditions de la table de hachage. Entrez une table de hachage où les clés sont des propriétés de travail et les valeurs sont des valeurs de propriété de travail.
Ce paramètre fonctionne uniquement sur les types de travaux personnalisés, tels que les travaux de flux de travail et les travaux planifiés. Elle ne fonctionne pas sur les travaux en arrière-plan standard, tels que ceux créés à l’aide de l’applet de commande Start-Job
. Pour plus d’informations sur la prise en charge de ce paramètre, consultez la rubrique d’aide pour le type de travail.
Ce paramètre a été introduit dans Windows PowerShell 3.0.
Type: | Hashtable |
Position: | 0 |
Valeur par défaut: | None |
Obligatoire: | True |
Accepter l'entrée de pipeline: | True |
Accepter les caractères génériques: | False |
-Force
Indique que cette applet de commande continue d’attendre les travaux dans l’état Suspendu ou Déconnecté. Par défaut, Wait-Job
retourne ou termine l’attente lorsque les travaux se trouvent dans l’un des états suivants :
- Terminé
- Raté
- Arrêté
- Suspendu
- Coupé
Ce paramètre a été introduit dans Windows PowerShell 3.0.
Type: | SwitchParameter |
Position: | Named |
Valeur par défaut: | None |
Obligatoire: | False |
Accepter l'entrée de pipeline: | False |
Accepter les caractères génériques: | False |
-Id
Spécifie un tableau d’ID de travaux pour lesquels cette applet de commande attend.
L’ID est un entier qui identifie de façon unique le travail dans la session active. Il est plus facile de mémoriser et de taper que l’ID d’instance, mais il est unique uniquement dans la session active. Vous pouvez taper un ou plusieurs ID, séparés par des virgules. Pour rechercher l’ID d’un travail, tapez Get-Job
.
Type: | Int32[] |
Position: | 0 |
Valeur par défaut: | None |
Obligatoire: | True |
Accepter l'entrée de pipeline: | True |
Accepter les caractères génériques: | False |
-InstanceId
Spécifie un tableau d’ID d’instance de travaux pour lesquels cette applet de commande attend. La valeur par défaut est tous les travaux.
Un ID d’instance est un GUID qui identifie de façon unique le travail sur l’ordinateur. Pour rechercher l’ID d’instance d’un travail, utilisez Get-Job
.
Type: | Guid[] |
Position: | 0 |
Valeur par défaut: | None |
Obligatoire: | True |
Accepter l'entrée de pipeline: | True |
Accepter les caractères génériques: | False |
-Job
Spécifie les travaux pour lesquels cette applet de commande attend. Entrez une variable qui contient les objets de travail ou une commande qui obtient les objets de travail. Vous pouvez également utiliser un opérateur de pipeline pour envoyer des objets de travail à l’applet de commande Wait-Job
. Par défaut, Wait-Job
attend tous les travaux créés dans la session active.
Type: | Job[] |
Position: | 0 |
Valeur par défaut: | None |
Obligatoire: | True |
Accepter l'entrée de pipeline: | True |
Accepter les caractères génériques: | False |
-Name
Spécifie les noms conviviaux des travaux pour lesquels cette applet de commande attend.
Type: | String[] |
Position: | 0 |
Valeur par défaut: | None |
Obligatoire: | True |
Accepter l'entrée de pipeline: | True |
Accepter les caractères génériques: | False |
-State
Spécifie un état de travail. Cette applet de commande attend uniquement les travaux dans l’état spécifié. Les valeurs acceptables pour ce paramètre sont les suivantes :
- NotStarted
- Course
- Terminé
- Raté
- Arrêté
- Bloqué
- Suspendu
- Coupé
- Suspension
- Plombage
Pour plus d’informations sur les états de travail, consultez 'énumération JobState.
Type: | JobState |
Valeurs acceptées: | NotStarted, Running, Completed, Failed, Stopped, Blocked, Suspended, Disconnected, Suspending, Stopping, AtBreakpoint |
Position: | 0 |
Valeur par défaut: | None |
Obligatoire: | True |
Accepter l'entrée de pipeline: | True |
Accepter les caractères génériques: | False |
-Timeout
Spécifie le temps d’attente maximal pour chaque travail en arrière-plan, en secondes. La valeur par défaut, -1, indique que l’applet de commande attend la fin du travail. Le minutage commence lorsque vous envoyez la commande Wait-Job
, et non la commande Start-Job
.
Si cette durée est dépassée, l’attente se termine et l’invite de commandes retourne, même si le travail est toujours en cours d’exécution. La commande n’affiche aucun message d’erreur.
Type: | Int32 |
Alias: | TimeoutSec |
Position: | Named |
Valeur par défaut: | None |
Obligatoire: | False |
Accepter l'entrée de pipeline: | False |
Accepter les caractères génériques: | False |
Entrées
System.Management.Automation.RemotingJob
Vous pouvez diriger un objet de travail vers cette applet de commande.
Sorties
System.Management.Automation.PSRemotingJob
Cette applet de commande retourne des objets de travail qui représentent les travaux terminés. Si l’attente se termine parce que la valeur du paramètre de délai d’attente est dépassée, Wait-Job
ne retourne aucun objet.
Notes
Par défaut, Wait-Job
retourne ou termine l’attente lorsque les travaux se trouvent dans l’un des états suivants :
- Terminé
- Raté
- Arrêté
- Suspendu
- Déconnecté Pour diriger
Wait-Job
pour continuer à attendre les travaux suspendus et déconnectés, utilisez le paramètre Forcer.