Windows PowerShell Procédure pas à script

Don Jones

Contenu

N'utilisez pas de variables de façon excessive
Noms de variables explicites
Simplifier les comparaisons
Ne pas interrompre votre script
Boucle la boucle
Ne pas être si automatique
Montrez-moi vos scripts

Une offre (qui signifie encore) apportées récemment aux lecteurs de mon ConcentratedTech.comblog : envoyez-moi vos scripts Windows PowerShell et je vous les passer en revue et proposer des suggestions que je vous aider à améliorer les. L'idée provenance en fait d'une enquête mes blogueurs co et j'ai exécuté, un lecteur suggérée que ce serait fournir un moyen formidable réelles pour les personnes améliorer leurs compétences scripts. Au cours des quelques mois, j'ai remarqué quelques tendances que trouver moi-même effectuer plusieurs suggestions particuliers à plusieurs reprises. Si vous avez compilé une liste de les partager avec vous ici.

Me laisser premier état, cependant, que n'importe quel script qui obtient le travail terminé (avec succès et sans endommager secondaire, de cours) est un bon script. Parmi les choses que je suis suggérant peut sembler nitpicky et certains d'entre eux sont certainement. Toutefois, chacun de mes suggestions a certains avantages, dont je vais essayer de souligner que je vais.

N'entrent en infraction si vous effectuez en fait quelques-unes des «incorrectes conseillées"je remarquer. Je sais que beaucoup de personnes ce script dans Windows PowerShell scripts avec VBScript a commencé et parmi ces «conseillées incorrectes» sont en fait très courants dans le monde de VBScript. Ceci est une bonne opportunité, puis, découvrez comment Windows PowerShell et VBScript sont un peu différents et comment écrire des scripts qui utilisent des avantages uniques que Windows PowerShell a à offrir.

Qui dit, voici mon suggestions de common six supérieure apportées au cours des quelques mois.

N'utilisez pas de variables de façon excessive

Bien sûr, les variables sont utiles, mais nous allons pas obtenir terre. J'ai voir beaucoup de ce type de script :

$varfile = "c:\names.txt"
$varexists = Test-Path $varfile
if ($varexists –eq $false) {
  Write-Output "The file $varfile does not exist"
  break
}
$varnames = Get-Content $varfile

Il existe quelques méthodes que je souhaite voir modifiées dans un exemple comme suit. Tout d'abord, il est peu nécessaire de respecter toutes ces informations dans des variables. Il est possible de réécrire ce avec moins de variables. Pourquoi pris la peine ? L'interpréteur de commandes peut peu variables combien vous utilisez, mais je suis un fan grand, grand de rendre les scripts comme lisible que possible afin quelqu'un peut lire le script sur papier ou dans un éditeur de script et pouvoir deviner ce que fait le script. Les variables plus vous inclure, plus une personne devra suivre dans son en-tête — et la moins probable qu'il pourrez savoir ce que le script est à. Si vous ne savez pas le script sur papier, je suis moins susceptible d'être en mesure de déboguer le script s'il existe un problème. Afin que vous souhaitez en réécrivant cet exemple comme suit :

$varfile = "c:\names.txt"
If ((Test-Path $varfile) –eq $false) {
Write-Output "The file $varfile does not   exist"
  break
}
$varnames = Get-Content $varfile

Tous les je fais vraiment est éliminant la variable varexists $ et utilisant directement le résultat de test-Path. De cette manière, je n'est nécessaire de regarder si construire, consultez varexists $, puis revenir et déterminer quel varexists $ est censé pour contenir. Il est moins pour moi de suivre de mon crane. Notez que j'ai laissé $ varfile ; c'est car vous utiliser ces informations trois fois, si vous êtes réutiliser plusieurs fois les informations, puis il convient de placer dans une variable.

Noms de variables explicites

En reprenant l'exemple précédent, souvenez-vous toujours que les noms de variables vous aideront n'oubliez pas que d'une variable. Inutile d'utiliser des préfixes des noms comme «var», car le caractère $ vous indique que c'est une variable. En fait, nom préfixes comme "str" pour les chaînes ou "int" pour les entiers est obsolète («c'est donc 1993» est vous dire que lorsque je suis apprentissage classes). Utilisez simplement les noms de variable simples. Voici l'exemple de réécriture :

$filename = "c:\names.txt"
If ((Test-Path $filename) –eq $false) {
Write-Output "The file $filename does not exist"
  break
}
$computernames = Get-Content $filename

Simplifier les comparaisons

Je ne suis pas un ventilateur d'opérateurs de comparaison Windows PowerShell — celles tels que –gt, - lt, - eq et ainsi de suite. Mon manque d'affection provient probablement de mon expérience long avec VBScript, où je pourrais utiliser opérateurs familiers tels que >, < et =. Beaucoup d'entre vous reconnaissent probablement ces opérateurs de niveau scolaire mathématiques leçons et ils nécessitent donc moins analyse mentale lorsque vous lisez les. Puis, dans la mesure du possible, j'aime Évitez d'utiliser un opérateur. Et n'importe quelle condition dans laquelle vous rechercher quelque chose à être true ou False est l'occasion pour vous débarrasser d'un opérateur :

$filename = "c:\names.txt"
If (-not (Test-Path $filename)) {
Write-Output "The file $filename does not exist"
  break
}
$computernames = Get-Content $filename

Étant donné que la cmdlet test-Path retourne True ou False, il est inutile à comparer à True ou false. Tout à l'intérieur si construit parenthèses doit plus vers le bas à True ou false. Normalement, vous pouvez utiliser une comparaison pour atteindre qui, mais si quelle que soit en y est déjà générer True ou False, vous pouvez simplement utiliser ces informations directement.

Je dois que l'opérateur –not est je réellement convient. Il est plus comme anglais courant que l'équivalent! =, opérateur utilisé par de nombreux langages.

En outre, je doit commenter les parenthèses que je suis placer autour de test-Path et son paramètre d'entrée, $ nom de fichier. J'ai mettant commandes entre parenthèses car il permet de me visuellement les saisir en tant qu'unité unique. Windows PowerShell utilise espaces plutôt que tout autre caractère pour séparer les éléments comme les commandes, les noms de paramètres et valeurs de paramètre. Entourant la chaîne toute commande de parenthèses m'afficher ensemble, sans forcer me fait examiner les espaces et déterminer où la commande démarre et s'arrête.

Ne pas interrompre votre script

La suggestion dernier que né pour cet exemple en cours d'exécution est le moyen que sa logique est créé. Si le fichier n'existe pas, je saut hors de script. Si le fichier existe, j'exécute jamais l'instruction break et donc le script se poursuit. Dans la mesure du possible, j'aime évitez saut pour quitter un script. Vous devez réécrire l'exemple, nouveau, comme suit :

$filename = "c:\names.txt"
If (Test-Path $filename) {
$computernames = Get-Content $filename
  # do whatever we planned to do
} else {
Write-Output "The file $filename does not exist"
}

De cette manière, vous avez simplifié la logique de si construire. J'ai également éliminé la nécessité d'utiliser l'instruction de saut, qui réduit la confusion quant à ce que fait le script. Je suis le premier à admettre que cette suggestion est absolument un nitpick, mais je pense que bonnes pratiques de codage faciliter mieux les scripts, et c'est sans aucun doute préférable que bailing hors d'un script du milieu. Ce type de construction est plus facile à déboguer et il est beaucoup plus facile de suivre sur du papier si vous êtes un script et tenter de deviner ce qu'il fait.

Boucle la boucle

Plusieurs scripts Qu'avoir examinée nécessaires pour lire les informations dans un fichier texte et boucle dans chaque ligne du fichier. Par exemple, vous souhaitez contacter une série d'ordinateurs, afin que vous pouvez répertorier leurs noms, un nom par ligne, dans un fichier texte. Voici une construction commune que j'ai vus :

$line = 0
$names = get-content c:\names.txt
while ($line –lt $names.length) {
  # do something with $names[$line]
  $line++
}

Il charge le fichier dans la variable $ names et puis manuellement énumère la collection comme s'il s'agissait d'un tableau. La variable de ligne $ assure le suivi de la ligne que je travaille avec. Il fonctionne correctement, mais je fais un peu plus de travail que je dois faire, et je suis rendre le code un peu plus difficile pour quelqu'un d'autre lire ultérieurement. La construction ForEach dans Windows PowerShell est un peu plus appropriée pour énumérer des collections. (Techniquement, Get-Content renvoie une collection, n'est pas un tableau). Essayez plutôt :

Foreach ($name in (Get-Content c:\names.txt))
{
  # do something with $name
}

Il y a quelques avantages ici. Conformément à ma suggestion précédente, je suis placer l'appel à Get-Content directement dans la construction, étant donné que je pense que c'est un peu plus claire à ce qui se passe. ForEach énumère via la collection entière, indépendamment de la durée pendant laquelle il. Chaque fois, il prendre l'élément suivant dans la collection et que cet élément dans la variable de nom $. De sorte que le nom de la variable représente ce qu'elle contient, une nom de l'ordinateur. Et qui facilite le script pour lire et suivre.

Windows PowerShell Q & A

Q Existe-t-il un moyen de définir un alias personnalisé permanent dans Windows PowerShell ?

A si vous avez déjà créé un nouvel alias, vous avez probablement remarqué qu'il disparaît lorsque vous fermez le shell. Par exemple, cela crée un nouveau d alias, qui est un raccourci vers la commande Get-ChildItem :

Nouvel alias d Get-ChildItem

Mais lorsque je ferme l'interpréteur de commandes, l'alias est perdu. L'astuce consiste à créer un profil Windows PowerShell. Dans votre dossier documents, créez un nouveau dossier nommé WindowsPowerShell. Dans ce dossier, créez un fichier texte nommé profile.ps1. Dans ce fichier texte, placez les commandes que vous souhaitez exécuter automatiquement chaque fois que le shell démarre, y compris une nouvelle définition d'alias. Le profil garantit que les commandes exécutées chaque fois que vous lancez le shell, créez un alias «permanent» est toujours disponible dans Windows PowerShell.

Vous ne souhaitez pas vous inquiétez sur quelle ligne je suis utilisation ou conserver une variable de ligne $ pour assurer le suivi des qui — la construction ForEach fait pour moi. Élimination des trois lignes de code rend le code un peu plus concis et que vous effectuer le suivi de moins d'éléments dans votre tête lorsque vous essayez de savoir ce que fait le script.

Ne pas être si automatique

L'application une pratique vous voulez vraiment nip de la tige est une pratique de suppression des erreurs de shell dans un script entier. Supposons que vous regardez dans un script qui contient ce droit de ligne du haut :

$ErrorActionPreference = "SilentlyContinue"

Arrêter immédiatement.

Ce n'est pas rendre erreurs disparaître, mais il ne les supprime. Oui, il est certainement parfois lorsque vous allez anticiper et souhaitez ignorer une certaine erreur, comme lorsque vous utilisez WMI (Windows Management Instrumentation) pour vous connecter aux ordinateurs distants potentiellement ne sont pas disponibles. Mais il y a jamais une raison globalement ignorer les erreurs. Messages d'erreur sont utiles et signalez des problèmes que vous pouvez parfois résoudre.

Si vous souhaitez ignorer les erreurs pour une applet de commande particulier, vous pouvez le faire en ajoutant le paramètre «SilentlyContinue» –EA à cette applet de commande. Si vous souhaitez ignorer les erreurs pour plusieurs commandes dans une ligne, soit ajouter le paramètre –EA à chacun ou ajoutez la ligne de ErrorActionPreference $ immédiatement avant les commandes et après ces commandes, ajoutez :

$ErrorActionPreference = "Continue"

Cela définit la gestion des erreurs pour normal.

Personnellement, je n'aime pas la désactivation erreurs tout sauf si je suis erreurs ces moi-même. Par exemple :

Trap {
  # output error to a log file or something
}
Get-WmiObject Win32_Service –computerName $remote –EA Stop

Cet exemple brève montre comment le paramètre de "Stop" –EA générera exceptions trues, plutôt que simplement messages d'erreur, en donnant une possibilité pour intercepter et les gérer vous-même. Vous pourriez les enregistrer dans un fichier, afficher un message d'erreur plus conviviale ou faire autre chose à cet effet.

Montrez-moi vos scripts

Comme j'ai dit, certaines d'entre elles ont été un nitpicky bits — mais tous les avantages méritent d'être prise en compte. Je vous inviter à partager vos propres scripts Windows PowerShell. Vous passez en revue quelques chaque mois et publier mes suggestions sur ConcentratedTech.com. N'hésitez pas à rechercher certains de mes précédentes suggestions et peut-être même envoyer vos propres scripts pour révision. J'espère entendre de vous !

Don Jones est cofondateur de technologie concentré. Vous pouvez astuces sur Windows PowerShell et autres sujets informatiques, ainsi que pour contacter Don, sur son blog à ConcentratedTech.com.