Planifiez vos tâches avec des scripts PowerShell sur Windows Server

Gagnez en lisibilité

En plus de bases solides sur le développement en PowerShell, vous savez désormais utiliser votre IDE PowerShell ISE pour vous aider à développer au mieux vos scripts.

Je vais maintenant vous poser une question qui au premier abord paraît très simple :

Pour qui développez-vous ?

Je vous laisse un peu de temps de réflexion, car sous cette question toute simple se cache en vérité une réponse plus profonde et intéressante qu’on pourrait le croire.

Vous aviez raison, il y avait bien un piège dans cette question, et vous n’êtes pas tombé dedans. Félicitations ! :)

Si vous pensiez développer pour vous tout seul, je suis désolé, mais c’est très probablement faux.

Si vous scriptez en PowerShell, c’est sûrement pour automatiser des tâches qui sont chronophages. Peut-être êtes-vous un professionnel de l’informatique, peut-être pas. 

À ma question “Pour qui développez-vous ?”, une des réponses pourrait être “pour mes collègues, mon service et moi-même”.

C’est une réponse tout à fait excellente. Et si c’est celle à quoi vous avez spontanément pensé, sachez que vous êtes avec le bon état d’esprit.

Si vous êtes persuadé de scripter pour vous uniquement, je vous propose cette petite gymnastique d’esprit en vous posant la question hautement philosophique que voici :

“Est-ce que le “vous” de 6 mois ou un an dans le futur ne pourrait pas être considéré comme une autre personne, avec des connaissances et des expériences en plus ?”

Si je vous pose cette question, et si j’essaie de mettre cette petite gymnastique cérébrale dans le sujet, c’est pour que vous compreniez l’importance des éléments qui vont venir.

La première bonne pratique que vous allez devoir mettre en place est le nommage de vos variables.

Quel est par exemple la ligne de code la plus simple à comprendre pour vous entre :

 $c = $a / $b 

et

 $resultat = $numerateur / $denominateur   ?

Bien nommer une variable est essentiel pour pouvoir avoir un code lisible et compréhensible. Et ça vous permettra aussi au passage de juger de sa pertinence dans le code.

Une des bonnes pratiques en matière de développement de script est ce qu’on appelle le cartouche. Le cartouche est un bloc de commentaire qui apparaît en début de script, sur quelques lignes, et qui sert en quelque sorte d’en-tête.

Il est important de prendre en compte les deux points suivant pour ce cartouche :

• Il sera la première chose qui sera vue/lue lors de l’ouverture du script.

• Il n’est pas interprété par PowerShell. Il est donc libre au niveau des informations présentées.

Néanmoins, ce cartouche a une grande importance. Pour votre collègue ou votre client, c’est un outil de communication. Pour votre “vous” de dans un an, c’est un outil qui vous permettra de vous rappeler les informations importantes.

Le cartouche commence par les caractères  <#  et se termine par  #>  , et devrait contenir les informations suivantes quand il est bien rempli.

Vous voulez un exemple de cartouche ? Je peux vous montrer celui que j’ai mis en place pour un script de création de dossiers utilisateurs.

Commentez votre code

Le cartouche, je vous l’ai dit juste avant, consiste en un bloc de commentaire en début de script.

Le commentaire peut être mis dans un bloc, comme le cartouche, via les balises d’ouverture et de fermeture <# et #>, mais il peut aussi être mis sur une seule ligne via le caractère #.

Vous l’aurez compris, le cartouche n’est pas le seul commentaire qui est bon à mettre dans le script.

La fonction principale du commentaire est de donner une information pertinente au développeur, qui lui permette d’analyser le script plus rapidement et correctement.

Le commentaire va pouvoir être placé… partout ! Ou du moins, partout où vous le jugerez nécessaire pour vous aider à comprendre votre code.

Le commentaire peut aussi être ajouté pour préciser ce que vous souhaitez faire.

Si, par exemple, vous avez trouvé une instruction assez confuse pour exécuter une action bien précise, vous pouvez dans ce cas mettre un commentaire juste avant l’instruction pour l’expliquer brièvement avec vos propres mots.

Si vous avez du code que vous savez fonctionnel, mais que vous souhaitez garder en mémo qu’il faudrait l’optimiser, pareil, vous pouvez à la fin de la ligne décider de mettre un petit commentaire pour indiquer une future évolution à mettre en place.

Codez des scripts interactifs

N’avez-vous jamais rêvé de pouvoir communiquer avec la machine ? Ou que la machine communique avec vous ?

Il peut être très utile dans un script de pouvoir demander des informations à l’utilisateur qui va l’exécuter. En d’autres termes, vous n’allez pas dialoguer avec la machine, mais dialoguer avec un utilisateur par le biais de votre script.

Par cet exemple, vous aurez peut-être déjà compris qu’à un moment il va nous falloir poser des questions, et à un autre moment, il va falloir y répondre.

Ces entrées-sorties vont pouvoir être gérées en PowerShell. Vos scripts interactifs vont tourner autour des deux cmdlets suivantes :

Write-Host 

et

Read-Host

Si vous parlez un peu anglais, vous aurez traduit ces cmdlets comme étant, la première une instruction qui permet d’afficher à l’invite de commandes PowerShell des données ( Write-Host  ), et l’autre une instruction qui lui permet de poser une question à l’utilisateur, en lisant une donnée entrée par l’utilisateur via son clavier ( Read-Host  ).

Vous pouvez utiliser  Write-Host  avec une chaîne de caractères, ou avec une variable.

•  Write-Host “Voici mon message” 

ou

•  Write-Host $uneVariable 

Comme je vous l’ai dit, le Read-Host  va vous permettre de poser une question. Et une question, ça fait quoi ? Eh bien, ça attend une réponse.

C’est un peu comme ça que fonctionne le Read-Host  . En effet, vous pouvez essayer, vous verrez que dès qu’il arrive sur cette cmdlet, il va attendre que l’utilisateur du script entre une information.

Concernant la syntaxe du Read-Host  , on est proche de celle du Write-Host  . On appelle notre cmdlet suivi du message, ou d’une variable contenant le message.

Mais par contre, la grosse différence avec le Write-Host , c’est qu’on peut stocker la réponse dans une variable que vous allez pouvoir réutiliser.

À vous de jouer !

Un des collègues de votre service vient vous voir pour vous demander un avis sur son travail. Il commence le PowerShell, et n’est pas sûr que son code soit suffisamment lisible.

Vous vous apercevez que le script ne respecte aucune bonne pratique de mise en forme.

Proposez-lui une version modifiée mais toujours fonctionnelle du script, et qui respectera les bonnes pratiques de mise en forme que vous avez pu voir tout au long du chapitre.

$p = Read-Host "Entre le mot de passe"
Write-Host "Vous avez entré : $p"

$r = $p.ToLower()
$r = (Get-Culture).TextInfo.ToTitleCase( $r )
Write-Host "Voici le mot de passe modifié : $r"

Pour vous corriger, c’est simple, posez-vous la question suivante : Est-ce que le script a…

• Un cartouche ?

• Des variables correctement nommées ?

• Des commentaires pertinents expliquant un minimum le fonctionnement du programme ?

• Une fois que tous ces éléments seront ajoutés, le script n’en sera que plus lisible.

En résumé

• Vous scriptez rarement uniquement pour vous-même.

• Un script lisible permet une meilleure relecture, et une analyse plus rapide.

• Le script interactif interagit avec l’utilisateur qui l’utilise, via les cmdlets  Read-Host  et  Write-Host  .

• L’intérêt des variables est central dans un script interactif.       

• Une variable bien nommée est souvent plus efficace qu’un commentaire.           

Vous avez maintenant toutes les cartes en main pour développer des scripts bien structurés, bien lisibles et interactifs. Vous allez désormais pouvoir essayer de produire un code réutilisable.