Redgate Hub

Pendant que vous travaillez avec une session PowerShell, vous pouvez modifier son état (ou environnement) de plusieurs façons : Vous pouvez importer des modules, créer des fonctions, spécifier des alias ou définir des variables, pour n’en citer que quelques-uns. Mais toutes ces modifications sont transitoires : leurs effets disparaissent dès que vous fermez la session PowerShell. Cependant, PowerShell fournit un mécanisme, appelé profil PowerShell, qui vous permet de recréer ces constructions et paramètres environnementaux chaque fois que vous démarrez une nouvelle session PowerShell. Et si un profil est bon, plusieurs ne seraient-ils pas meilleurs ? Il s’avère qu’une seule session PowerShell peut utiliser l’un (ou l’ensemble) de quatre profils différents, et différents hôtes PowerShell offrent encore plus de choix de profils : Mais c’est en fait beaucoup plus simple à utiliser que tout cela peut paraître, une fois que vous appréciez où s’insèrent toutes les pièces mobiles. Jetons un coup d’œil.

Le shell dans PowerShell

Il existe une distinction entre le shell et l’hôte dans PowerShell. Don Jones, dans son post bien intitulé The Shell vs. The Host, explique que vous – en tant qu’utilisateur tapant au clavier – n’interagissez pas directement avec le shell (ou moteur) de PowerShell. Plus précisément, vous interagissez avec une application hôte (comme powershell.exe ou powershell_ise.exe) qui crée un espace d’exécution (une instance du moteur PowerShell). Vous pouvez réellement voir la distinction en affichant le contenu de la propriété Name de la variable système $Host à côté de la variable $ShellId. Vous verrez que, si vous examinez les valeurs des trois hôtes PowerShell les plus courants, ils utilisent tous le même moteur (shell) alors que chacun présente une interface utilisateur (hôte) différente.

Host	$Host.Name	$ShellId
PowerShell	ConsoleHost	Microsoft.PowerShell
PowerShell ISE	Windows PowerShell ISE Host	Microsoft.PowerShell
Visual Studio Package Manager Console	Hôte du gestionnaire de paquets	Microsoft.PowerShell

D’autres hôtes PowerShell pourraient potentiellement avoir des valeurs $ShellId différentes (par exemple, certains des IDE PowerShell disponibles gratuitement incluent PowerGUI, PowerShell Analyzer et PowerShell Plus, mais je n’ai pas vérifié leurs valeurs $ShellId).

Le profil PowerShell

Un profil PowerShell n’est rien de plus qu’un nom fantaisiste pour un script qui s’exécute au démarrage d’un hôte PowerShell. En citant l’aide standard de PowerShell sur about_profiles, « Vous pouvez utiliser le profil comme script de connexion pour personnaliser l’environnement. Vous pouvez ajouter des commandes, des alias, des fonctions, des variables, des snap-ins, des modules et des lecteurs Windows PowerShell. Vous pouvez également ajouter d’autres éléments spécifiques à la session à votre profil afin qu’ils soient disponibles dans chaque session sans avoir à les importer ou à les recréer. »

Chaque hôte PowerShell prend en fait en charge deux profils, l’un est de niveau utilisateur, distinct pour chaque utilisateur, et l’autre est de niveau système, commun à tous les utilisateurs. Il devrait s’agir d’un paradigme familier que vous aurez vu avec de nombreuses applications Windows. PowerShell ajoute cependant sa propre tournure unique : il distingue de la même manière le niveau hôte (un profil pour chaque hôte) et le niveau système (un profil commun à tous les hôtes).

Ainsi, en prenant toutes les combinaisons d’utilisateurs et d’hôtes, vous pourriez potentiellement utiliser n’importe lequel (ou tous) de quatre profils différents :

• Tous les utilisateursTous les hôtes
• Tous les utilisateursHôte actuel
• Utilisateur actuelTous les hôtes
• Utilisateur actuelHôte actuel

Ces profils coexistent tous pacifiquement, vous devez donc ensuite être conscient de la préséance – ils sont listés ci-dessus dans l’ordre d’exécution. Si vous deviez définir la même variable dans les quatre profils, la variable aura, une fois que vous lancerez un hôte PowerShell et recevrez finalement une invite, la valeur attribuée par le dernier profil, CurrentUserCurrentHost, car chaque profil traité successivement écrasera cette variable avec sa valeur. Un autre exemple, montrant la coopération entre les profils plutôt que la contention, pourrait être d’incrémenter une variable. D’abord, définissez-la et initialisez-la à une valeur de départ (par exemple $someVar = 0) dans AllUsersAllHosts, puis incrémentez-la dans chacun des autres profils (par exemple $someVar++ ou peut-être $someVar += 5 selon ce que vous voulez en faire).

Sur lequel des quatre utiliser, cela dépend largement de vos propres besoins : si vous utilisez un ordinateur dédié (c’est-à-dire non partagé avec quelqu’un d’autre), vous n’avez pas besoin de vous soucier des profils « tous les utilisateurs ». Si vous utilisez plusieurs hôtes, vous voudrez peut-être différencier certaines choses entre un profil « tous les hôtes » et un profil d’hôte spécifique. Je donnerai plus de détails à ce sujet ci-dessous dans « Combien de profils avez-vous besoin ? »

La variable $Profile

Pour créer ou modifier l’un des profils, vous devez bien sûr savoir où les trouver. PowerShell lui-même peut facilement vous le dire, mais il peut aussi simplement en ouvrir un pour le modifier sans que vous ayez à vous soucier explicitement du chemin. Pour voir le chemin, affichez la valeur de la variable $Profile. Elle révèle un seul chemin d’accès au fichier, qui est le chemin d’accès au profil CurrentUserCurrentHost. Dans un hôte PowerShell standard, le mien montre ceci:

Notez que cela ne fait aucune déclaration sur l’existence du fichier, seulement que c’est le chemin qu’il doit avoir s’il existe. Pour vérifier l’existence, utilisez Test-Path :

Si le profil n’existe pas, vous pouvez facilement le créer :

Et si vous voulez avoir cela dans un script, vous pouvez alors combiner ce qui précède, en créant le fichier seulement si nécessaire :

Enfin, pour modifier le profil, il suffit d’invoquer votre éditeur préféré sur le fichier, ou vous pouvez toujours utiliser l’omniprésent éditeur notepad :

Tous les exemples ci-dessus concernent le profil « par défaut » (CurrentUserCurrentHost), comme mentionné. Mais vous pouvez appliquer toutes les mêmes commandes à l’un des quatre profils par référence spécifique ; l’un ou l’autre produit le même résultat :

Substituer l’un des trois autres noms de propriétés de profil pour accéder à l’un des profils non par défaut.

Noms des fichiers de profil & Emplacements

La section précédente a expliqué comment modifier n’importe lequel de vos profils sans savoir réellement où ils se trouvent sur le système de fichiers, mais vous êtes un développeur ; vous avez une compulsion innée pour savoir où ils se cachent ! Le tableau montre le chemin de chacun d’entre eux. ( HostId est un placeholder, expliqué dans un instant.)

Profil	Location
AllUsersAllHosts	$PsHome\profile.ps1
AllUsersCurrentHost	$PsHome\HostId_profile.ps1
CurrentUserAllHosts	$HomeDocuments\WindowsPowerShell\profile.ps1
CurrentUserCurrentHost	$HomeDocuments\WindowsPowerShell\HostId_profile.ps1

En examinant les emplacements, il est simple de comprendre les conventions de dénomination. Les profils de niveau système – ceux de tous les utilisateurs – se trouvent dans le répertoire système pointé par $PsHome. Les profils de niveau utilisateur se trouvent sous le répertoire personnel de chaque utilisateur. Le seul point qui nécessite une explication est le HostId indiqué pour les profils spécifiques aux hôtes dans la table. Malheureusement, cet identifiant d’hôte n’a aucune ressemblance directe avec la description de l’hôte ni avec la propriété $Host.Name ! La façon de découvrir le HostId est simplement d’afficher la valeur de la variable $Profile, car elle fait partie du chemin. Par commodité, voici les valeurs de HostId pour les hôtes les plus courants:

Host	HostId	$Host.Name
PowerShell	Microsoft.PowerShell	ConsoleHost
PowerShell ISE	Microsoft.PowerShellISE	Windows PowerShell ISE Host
Visual Studio Package Manager Console	NuGet	Package Manager Host

Combien de profils avez-vous besoin ?

Tout système Windows standard a deux profils pour l’hôte PowerShell standard, deux pour l’hôte PowerShell ISE, et deux pour tous les hôtes – six en tout au minimum. Si l’on ajoute le gestionnaire de paquets VS que j’ai présenté, cela fait deux de plus. Ajoutez d’autres IDE PowerShell – deux de plus pour chacun. Comment gérez-vous autant de profils ?

Interpréter la doctrine officielle MSDN ( about_profiles) envisager une solution tripartite.

• Premièrement, mettez les choses vraiment communes dans AllUsersAllHost.
• Deuxièmement, s’il y a des particularités dans des hôtes particuliers, utiliser AllUsersCurrentHost pour ces hôtes mécréants.
• Enfin, laissez chaque utilisateur gérer ses propres préférences et paramètres dans des profils spécifiques à l’utilisateur.

Mais là encore, il pourrait y avoir de nombreux profils différents pour « l’hôte actuel », tant au niveau du système qu’au niveau de l’utilisateur. Une bonne référence, alors que vous réfléchissez à vos choix ici, est le post d’Ed Wilson (The Scripting Guy) Deciding Between One or Multiple PowerShell Profiles. Il y inclut une liste d’avantages et d’inconvénients liés au choix entre un profil et plusieurs profils. Mais pour moi, les avantages d’un profil unique l’emportent largement sur ceux des profils multiples. Il faut un peu plus de travail pour le mettre en place, mais vous pouvez toujours tenir compte des différences spécifiques à l’hôte tout en ayant tout à un seul endroit, ce qui rend la maintenance beaucoup plus simple au fil du temps.

La plupart des choses de votre profil seront probablement communes à n’importe quel hôte, donc l’utilisation d’un seul profil signifie que tout changement sur la route sera fait dans exactement un seul fichier. Pour les choses qui diffèrent entre les hôtes, il suffit d’inclure une section spécifique à chaque hôte dont vous vous souciez. Le mien inclut quelque chose comme ceci :

Notez comment j’identifie l’hôte actuel avec $Host.Name puis exécute le code de manière sélective. Vous voyez les exemples ci-dessus pour l’hôte PowerShell standard ainsi que pour l’hôte PowerShell ISE. Pour le premier, il charge l’extension PSReadline qui ne fonctionne que dans l’hôte PowerShell. Pour le second, il charge le PsISEProjectExplorer et le module ISE Steroids, qui ne peuvent tous deux fonctionner que dans l’environnement ISE.

Enfin, si vous utilisez Git et que l’installateur particulier que vous avez utilisé a créé un hôte PowerShell Git pour vous, notez qu’il ne peut pas être distingué de l’hôte PowerShell standard par le $Host.Name. Au lieu de cela, j’ai identifié une variable définie de manière unique, $env:github_shell, qui est uniquement présente dans l’hôte à saveur Git.

Que mettre dans votre profil

La réponse à cette question dépend de vos besoins individuels, elle doit donc être très abstraite : mettez dans votre profil ce que vous pouvez utiliser pour être plus productif. Il n’y a donc pas de réponse unique à cette question, mais je peux certainement fournir quelques suggestions pour faire jaillir votre créativité. Vous venez de voir ci-dessus quelques exemples d’importation de modules tiers pour ajouter des fonctionnalités à l’hôte donné. Outre les importations de modules, les sections suivantes fournissent quelques idées pour vous faire réfléchir à ce que vous pourriez vouloir y mettre. Jetez également un coup d’œil à la rubrique Qu’y a-t-il dans votre fichier PowerShell `profile.ps1` ? (sur StackOverflow) pour de nombreux autres exemples.

Alias

De nombreuses cmdlets PowerShell intégrées ont des alias ; certaines ont plusieurs alias. Vous pouvez, par exemple, utiliser ls ou dir ou gci au lieu de taper Get-ChildItem. Pour ceux que vous utilisez régulièrement et qui ne fournissent pas d’alias (ou pour vos propres fonctions et cmdlets personnalisés), vous pouvez créer vos propres alias avec Set-Alias. Set-Alias est approprié si vous voulez simplement abréger le nom de la cmdlet ou de la fonction. Mais parfois, vous pouvez vouloir qu’un alias comprenne, par exemple, un nom de cmdlet plus un paramètre que vous avez tendance à toujours utiliser. Dans ce cas, vous pouvez émuler un alias avec une simple fonction. Pour illustrer, considérons le cmdlet Import-Module. Je l’utilise fréquemment et je préfère que toutes mes cmdlets à usage fréquent utilisent simplement la première lettre de chaque composant. Cela configure l’alias im pour le faire :

Mais étant un développeur, je dois aussi utiliser fréquemment Import-Module avec le commutateur -Force. Donc pour cela, je dois avoir recours à une fonction. Pour ma convention de nommage, j’ajoute la première lettre du switch, d’où imf ici:

Je peux alors utiliser, par exemple, im foobar pour faire une importation vanille, ou imf foobar pour importer avec -Force appliqué.

Fonctions simples

Les fonctions ont juste été mentionnées comme un moyen de créer des pseudo-aliases, c’est-à-dire essentiellement pour vous éviter de taper. Mais, bien sûr, elles ne sont pas limitées à cet objectif. Vous pouvez inclure dans votre profil une variété de « one-liners » qui vous évitent à la fois de taper et de devoir vous souvenir des détails des cmdlets que vous utilisez moins souvent. Vite, comment afficher les 50 derniers éléments de votre historique de commandes ? Vous n’êtes pas certain ? La cmdlet à utiliser est Get-History (elle a un alias standard de la seule lettre h). Est-il facile de se souvenir de Get-History -Count 50 ou simplement de h50 ? Voici ma définition de h50 (et un h10 jeté juste pour faire bonne mesure):

Voici une fonction plus intéressante. Comment révèleriez-vous le cmdlet derrière un alias, le chemin d’accès à un exécutable étant donné le seul nom du programme, les jeux de paramètres disponibles pour un cmdlet donné ou le contenu d’une fonction définie par l’utilisateur ? J’utilise ce one-liner pour faire tout cela (nommé d’après la commande unix/linux qui effectue la même chose):

Voici quelques résultats de son utilisation :

Enfin, un autre one-liner pratique qui fonctionne à nouveau comme la commande unix/linux, rapportant votre nom d’utilisateur qualifié de domaine :

Fonctions complexes

Il est probable que vous créiez certaines fonctions utilitaires au cours de votre travail qui sont beaucoup plus impliquées qu’un simple one-liner. Vous pourriez, bien sûr, simplement les intégrer dans votre profil, mais cela a tendance à rendre votre profil long et désordonné. Si vous avez une collection de telles fonctions, vous pouvez toujours les organiser en un véritable module PowerShell, puis ajouter un Import-Module dans votre profil pour les intégrer. Pour quelque chose entre ces deux extrêmes, considérez cette approche. Dans mon profil, j’ai cette séquence de commandes qui amène tous les scripts de mon répertoire local profile_scripts dans le champ d’application au démarrage:

$PSScriptRoot est une variable système standard qui n’existe que dans le contexte d’un script en cours d’exécution. Elle se résout en $Home\Documents\WindowsPowerShell\\. Ainsi, mon répertoire profile_scripts se trouve sous ce chemin. Tout script (sans les scripts de test) est source de points, ce qui le rend visible dans votre portée actuelle dès que vous avez une invite après le démarrage.

Exécuter des actions

Les éléments précédents de cette section sont tous passifs ; ils définissent des choses que vous utiliserez à un moment ultérieur après le démarrage. Mais vous pouvez également inclure des éléments actifs qui s’exécutent pendant le démarrage. Je vous recommande vivement d’utiliser le cmdlet « ne me laissez pas me tirer dans le pied » :

Langues qui sont faiblement typées (par ex.ex. JavaScript, PowerShell) vous donnent la possibilité de travailler en toute sécurité ou non, alors que les langages fortement typés vous obligent généralement à travailler en toute sécurité. La sécurité signifie principalement que vous ne pouvez pas utiliser une variable avant qu’elle ne soit déclarée. Cela permet d’éviter que des erreurs de frappe par inadvertance ne vous causent des ennuis considérables en essayant de comprendre pourquoi votre code ne fonctionne pas. (Vraisemblablement, les gens du langage faiblement typé pensent que certaines personnes pourraient trouver le fonctionnement en toute sécurité fastidieux, donc ils en font une option). Mettez simplement le Set-PSDebug dans votre profil. Soyez prudent. S’il vous plaît.

Les autres types d’actions que vous pourriez mettre dans votre profil sont des choses comme l’affichage de certaines statistiques, par exemple le temps de fonctionnement, l’espace disque, ou la politique d’exécution PowerShell. Si vous administrez plusieurs machines, vous pourriez vouloir voir les détails de la machine dans laquelle vous vous êtes  » téléguidé « , pour vous assurer que vous êtes sur la boîte que vous pensez être (nom de domaine, nom d’ordinateur, adresse IP, etc.).

Sécuriser votre profil

Lorsque vous traitez avec des ordinateurs, la sécurité doit toujours être prise en compte. Vous utilisez un pare-feu et un antivirus pour essayer de garder votre système en sécurité. De même, vous devez considérer les scripts PowerShell que vous exécutez – y compris vos propres profils. PowerShell offre une bonne prise en charge de la sécurité, à commencer par son paramètre par défaut qui ne vous permet pas d’exécuter de scripts ; dès le départ, vous ne pouvez utiliser les commandes PowerShell que de manière interactive. Vous devez ouvrir votre système juste assez pour vous permettre d’accomplir tout travail nécessaire en définissant la politique d’exécution de votre ordinateur (voir Set-ExecutionPolicy).

Mais dès que vous autorisez l’exécution de scripts, il y a une chance que vous exécutiez par inadvertance un script compromis. Cela n’a rien d’unique aux scripts PowerShell en soi – tout ce qui se trouve sur votre ordinateur pourrait être compromis – c’est juste que PowerShell vous aide à atténuer la situation. Pour ce faire, il vous permet de définir la politique d’exécution à différents niveaux de sécurité en fonction de vos besoins. Vous pouvez exiger que chaque script soit authentifié ou que seuls les scripts que vous téléchargez soient authentifiés, entre autres options. L’authentification, dans ce cas, fait référence à la signature des scripts avec une signature numérique (voir Set-AuthenticodeSignature) de sorte que, si un fichier est modifié (de manière malveillante ou non), la signature numérique détecterait la falsification et empêcherait le script de s’exécuter.

Gérer la sécurité de vos scripts PowerShell (y compris vos profils), cependant, n’est pas une entreprise triviale. (Elle ferait plus que doubler la longueur de cet article !) Mais beaucoup de bonnes informations existent déjà pour vous guider. Je vous recommande de commencer par un autre article ici sur Simple-Talk, PowerShell Day-to-Day SysAdmin Tasks de Nicolas Prigent : Securing Scripts. Il existe également plusieurs bonnes références dans la documentation de PowerShell : about_signing donne une bonne introduction au sujet ; New-SelfSignedCertificate vous permet de créer vos propres certificats auto-signés, et Get-ChildItem for Certificate révèle les différences peu connues dans Get-ChildItem lors du référencement de votre magasin de certificats. Microsoft fournit une référence ancienne mais toujours utile sur les meilleures pratiques de signature de code. Et Signing PowerShell Scripts de Geoff Bard vaut également le coup d’œil.

Get That Profile Out of the Way!

Maintenant, vous savez comment configurer votre profil, pourquoi il est utile, ce qu’il faut en faire et comment le sauvegarder. Mais comme tout super pouvoir, vous devez être conscient de son côté obscur. En fait, il ne s’agit pas d’un côté sombre en soi, mais il y a des moments où vous ne voulez tout simplement pas que votre ou vos profils vous gênent. Ou, de façon plus poignante, les profils d’autres personnes.

Il existe une variété de situations où vous pourriez vouloir réellement exécuter powershell.exe soit avec une commande littérale ou un fichier script à exécuter. Voici un seul exemple : disons que vous avez créé un script PowerShell que vous souhaitez partager avec un collègue. Contrairement aux fichiers batch, vous ne pouvez pas simplement double-cliquer sur un script PowerShell pour l’exécuter ; cela fait partie du modus operandi de sécurité de PowerShell pour préserver la sécurité de votre système. Mais cela est facile à contourner (non pas que je le recommande !) en créant un raccourci Windows standard ciblant powershell.exe avec votre fichier de script PowerShell comme paramètre.

Une autre utilisation, peut-être plus légitime, serait d’exécuter un script ou une commande PowerShell dans un fichier de construction. Comme MSBuild ne sait pas de manière innée comment exécuter des scripts PowerShell, vous exécuteriez généralement un script en le fournissant comme argument à powershell.exe.

Chaque fois que vous exécutez powershell.exe, cependant, vous ouvrez un nouvel hôte PowerShell. Et que se passe-t-il lorsque vous ouvrez un hôte ? Il exécute n’importe lequel (ou tous) de vos quatre profils ! Mais presque à chaque fois que vous ouvrez un hôte en invoquant directement powershell.exe, vous ne voulez pas que vos profils s’exécutent, ni pour la surcharge, ni pour les éventuels conflits qui pourraient en résulter. Gardez à l’esprit que si quelqu’un d’autre exécute un build où vous avez introduit une commande pour exécuter powershell.exe, c’est son profil qui sera exécuté sur sa machine, et vous n’avez aucune idée de ce qui pourrait s’y cacher. De plus, vous ne voulez pas dépendre de quelque chose dans un profil, car la première fois que quelqu’un qui ne connaît pas cette dépendance exécutera votre compilation, celle-ci échouera (peut-être mystérieusement). Il est donc plus sûr tout autour de simplement adopter la meilleure pratique de toujours ignorer les profils lorsque vous invoquez powershell.exe. (Je ne veux pas dire que vous devriez les ignorer, plutôt que vous devriez dire à PowerShell de les ignorer, bien sûr !

Ainsi, après tout ce suspense, le dénouement peut être un peu décevant : il suffit d’ajouter un -NoProfile en paramètre à powershell.exe.

Conclusion

Le profil PowerShell est votre ami. Avec la feuille de route exposée dans cet article, vous avez vu les types de profils à votre disposition et vous pouvez sélectionner ceux qui vous conviennent. Vous pouvez également choisir d’utiliser un seul profil, en distinguant les éléments spécifiques à l’hôte selon les besoins. Le profil est un outil simple mais puissant à votre disposition, pas du tout compliqué à utiliser, et ses utilisations ne sont limitées que par votre imagination. Le seul inconvénient est le temps que vous allez maintenant passer à chercher des éléments pratiques et intelligents à ajouter à votre profil. (Ai-je mentionné que vous devriez envisager d’inclure le module Go-Shell… ?)