Heading

J’ai inclus ce commentaire dans un script récent parce que le | Out-Null n’était pas quelque chose que je m’attendais à devoir faire, et je sais que dans un an, si je n’avais pas le commentaire à cet endroit, je me demanderais pourquoi je l’avais. Ou pire, je le supprimerais et je me demanderais ensuite pourquoi j’avais un message d’annulation qui continuait à s’afficher.

Notez que lorsque vous commencez un commentaire par un #, tout ce qui se trouve jusqu’à la fin de la ligne est traité comme un commentaire. Cela peut être utile par exemple lorsque vous faites des tests et que vous pourriez vouloir commenter la fin d’une commande.

Ceci vous permet plus tard de supprimer le commentaire et d’obtenir la –online version de l’aide, mais que faire si vous voulez un commentaire au milieu ? Là encore, PowerShell vous donne ce pouvoir.

Notez qu’en utilisant un commentaire de style bloc, vous avez la possibilité d’avoir un commentaire au milieu de votre commande et de continuer à exécuter ou interpréter les éléments à sa droite. Enfin, vous vous demandez peut-être « que faire si je veux imprimer un # ou faire quelque chose de similaire ? ». Si vous essayez

Vous constaterez qu’il n’écrit pas ce que vous voulez. Vous obtenez simplement :

C’est là que l’accent grave ` est utile.

Ceci va imprimer le message que vous voulez.

Vous pourriez aussi mettre toute cette chaîne entre guillemets :

Cela fonctionnerait, mais je voulais donner un exemple de la façon d’échapper au qualificatif #.

Si, comme moi, vous utilisez souvent l’ISE de PowerShell pour écrire des scripts, il y a une dernière astuce utile que je veux partager, mais dont je ne peux que décrire et donner quelques captures d’écran, sans réellement fournir un script pour cela. Il s’agit d’un raccourci clavier qui n’est pas spécifique aux commentaires, mais qui est utile si vous avez un morceau de code que vous voulez commenter, par exemple pour des tests. Placez le curseur au début de la ligne et, en maintenant la touche Shift-Alt enfoncée, utilisez les touches fléchées pour le déplacer vers le haut ou vers le bas. Vous remarquerez qu’une fine ligne (bleue sur mon écran) apparaît. Une fois que vous avez marqué les lignes que vous voulez commenter, tapez simplement un # et il apparaîtra au début de chaque ligne.

Voici un exemple de code à commenter :

En cliquant à droite du texte de la ligne 40 et après avoir appuyé plusieurs fois sur Shift-Alt et la flèche vers le haut, vous verrez apparaître la ligne bleue :

Après avoir appuyé sur # <space>, vous verrez les caractères ajoutés au code :

En guise de remarque, vous pouvez utiliser cette astuce n’importe où sur la ligne (donc si vous vouliez mettre un tas de commentaires à la fin d’un certain nombre de lignes, vous pourriez utiliser cette astuce pour mettre facilement le # pour vous) et n’est évidemment pas spécifique au commentaire, mais c’est l’un des usages les plus évidents. Vous pouvez également le faire en utilisant des expressions régulières. Mettez en surbrillance le bloc de code en question :

Puis Ctrl-H pour obtenir la boîte de dialogue Rechercher et remplacer. Assurez-vous que Rechercher dans la sélection et Expressions régulières sont sélectionnés :

Le signe d’insertion ^ est utilisé pour ancrer le début d’une ligne et bien sûr le # (il y a un espace à cet endroit) insère essentiellement un # et un espace à la fin des lignes mises en évidence. Notez que si vous ne parvenez pas à mettre en surbrillance un bloc de code, cela fonctionnera sur l’ensemble de votre script.

Et plus

Cependant, si c’était tout ce que les commentaires pouvaient faire dans PowerShell, cet article serait très court et ennuyeux (et mon éditeur secouerait la tête en disant : « Greg, j’ai besoin de plus de 850 mots ! »). Comme beaucoup de choses dans PowerShell, les créateurs ont ajouté des fonctionnalités qui le rendent plus puissant que ce à quoi on pourrait s’attendre.

Je préparais récemment une présentation que je donnais au Hampton Roads SQL Server User Group. Au cours de cette présentation, j’exécute un script dans PowerShell qui démarre et arrête SQL Server. Pour ce faire, je dois l’exécuter en tant qu’administrateur. Bien sûr, j’avais complètement oublié cela lors d’un exercice, et lorsque je l’ai exécuté en tant que moi-même, il a fini par produire plusieurs erreurs désagréables. Ce n’était pas une catastrophe, mais ce n’est pas ce que l’on veut pendant une démo. Cela m’a fait réfléchir à la façon dont je pourrais m’assurer que cela ne se produirait pas pendant le véritable exposé.

Ma première pensée était de trouver une certaine cmdlet qui vérifierait pour voir sous quel nom je suis connecté, puis abandonnerait si je n’étais pas le bon utilisateur. Une partie du problème avec cette approche bien sûr est que lorsque vous exécutez un programme (comme PowerShell ISE) en tant qu’administrateur, vous vous présentez comme l’utilisateur connecté. Cela allait être plus difficile que je ne le pensais.

Une fois de plus, PowerShell m’a surpris. La résolution de ce problème est triviale. Pour voir comment résoudre le problème, ouvrez l’ISE PowerShell en tant que vous-même (c’est-à-dire. ne sélectionnez PAS Exécuter en tant qu’administrateur et assurez-vous que votre utilisateur n’a pas de privilèges d’administrateur local) et entrez le code suivant :

Enregistrer ceci dans un fichier appelé exemple de service de redémarrage du minuteur.ps1 et essayez ensuite de l’exécuter. À moins que vous ne soyez un administrateur local sur votre machine, vous devriez obtenir un écran d’erreur similaire à celui ci-dessous.

Si vous exécutez ceci en utilisant l’option Run as Administrator, il devrait s’exécuter sans erreur. Dans cet exemple, l’échec est plutôt bénin, mais peut-être que vous écrivez un script où un échec ne serait pas si inoffensif. Pour résoudre ce problème, il suffit de mettre le commentaire suivant en haut du script ci-dessus et de le réenregistrer.

Maintenant vous aurez une erreur différente :

C’est encore un peu moche mais bien mieux que d’exécuter le script et peut-être casser quelque chose. Notez que si vous vous contentez de couper et coller le script dans une nouvelle fenêtre, mais que vous ne l’enregistrez pas, PowerShell tentera d’exécuter l’ensemble. En fait, le #requires est ignoré sauf s’il s’agit d’un fichier enregistré. Cela a résolu mon problème initial, mais m’a amené à examiner d’autres fonctionnalités dont je n’avais pas connaissance. Pour les #requires, il y a une liste entière :

Comme vous pouvez le voir, ceux-ci vous donnent beaucoup de pouvoir pour contrôler comment et quand votre script est exécuté. Le #Requires –Version est utile si votre script nécessite des fonctionnalités qui ne sont disponibles que dans une version plus récente de PowerShell. Notez qu’il s’agit d’un nombre minimum. La version de PowerShell que vous exécutez doit correspondre à ce nombre ou être supérieure. Vous ne pouvez pas l’utiliser pour exiger une version antérieure de PowerShell. Par exemple, une cmdlet utile que j’ai utilisée dans un script récent est compress-archive. Heureusement, ce script était spécifique au problème que j’essayais de résoudre, mais si j’essayais d’écrire un script plus général, je pourrais vouloir mettre #requires –Version 5.0 à la fin de mon script. Pour faire une démonstration, enregistrez le script suivant en tant que version requise exemple.ps1.

Si vous exécutez ceci dans votre instance PowerShell ISE existante, il devrait s’exécuter sans problème, mais si vous essayez de l’exécuter dans une version plus ancienne, comme PowerShell 2.0, le script se trompera sur la ligne #requires et n’exécutera jamais le reste du script. C’est le résultat souhaité.

Pour les tests, vous pourriez également mettre quelque chose comme –Version 99.99 et vous verrez des messages d’erreur similaires aux exemples ci-dessous, mais je voulais montrer comment cela fonctionnerait dans le monde réel sur des systèmes existants et également démontrer la capacité de la ligne de commande à se replier sur une version précédente de PowerShell.

Pour tester cela, vous devrez utiliser la version en ligne de commande de PowerShell et la démarrer comme suit :

Exécutez ensuite le fichier que vous avez enregistré ci-dessus requires version example.ps1. Vous devriez voir une erreur telle que :

Bien que je recommande de mettre le commentaire #Requires au tout début du fichier, en vérité, vous pouvez le mettre n’importe où et il agira de la même manière. Si vous recréez le fichier ci-dessus, mais déplacez le commentaire vers le bas après le Get-Process et enregistrez en tant que nécessite la version exemple Version 2.ps1.

Tentez de l’exécuter sous la version 2.0 comme ci-dessus, et vous obtiendrez une erreur similaire et l’ensemble du script ne s’exécutera pas.

Cela signifie que vous ne pouvez pas avoir une partie d’un script qui peut s’exécuter sous une ancienne version (ou s’exécuter en tant que non-administrateur) et ensuite une partie qui nécessite une version particulière ou à exécuter en tant qu’administrateur. Si vous voulez faire quelque chose comme ça dans le code, vous devez devenir plus intelligent. Enregistrez le script suivant sous le nom de Requiert la version exemple Version 3.ps1.

Si vous exécutez ceci sous la version 5 ou supérieure, il créera le fichier Process.txt et le zippera. Si vous l’exécutez sous une version antérieure, comme la –Version 2.0 ci-dessus, le script sera toujours capable de créer le fichier Process.txt puisque Get-Process est un cmdlet disponible dans la version 2.0. Comme Compress-Archive ne l’est pas, le script sautera cette étape et donnera un message d’erreur. C’est à vous de voir si vous voulez écrire des scripts capables de détecter la version de PowerShell et de se comporter différemment selon la version, mais dans de nombreux cas, si vous voulez simplement interrompre le script, le commentaire #Requires est de loin la façon la plus simple de gérer les choses.

Deux dernières mises en garde sur l’utilisation d’un commentaire #Requires. Il doit commencer au début de la ligne ; vous ne pouvez pas avoir d’espace ou de tabulation avant lui. En outre, vous ne pouvez pas essayer d’être plus malin que lui et le placer dans un bloc try/catch pour le traiter de manière plus élégante. Enregistrez le script suivant pour illustrer ces deux mises en garde : Requiert l’exemple de version Version 4.ps1.