Package de Windows PowerShell : Et les distribuer personnalisée Windows PowerShell
Vous pouvez accomplir certaines choses intéressantes avec point de l'approvisionnement, mais qui peuvent également conduire à certaines limitations si vous ne faites pas attention.
Don Jones
Point de l'approvisionnement est une astuce intéressante, mais il peut être difficile de supprimer des commandes ultérieurement si vous n'en avez besoin ou ultérieurement découvrir qu'ils sont en conflit avec un autre élément. Une fois que nous avons activé une commande dans un autonome, outil paramétré, réutilisable le mois dernier, j'ai trouvé deux limitations que nous devons résoudre.
Nous avons conçu l'outil comme une fonction avancée de Windows PowerShell, ce qui est également appelée une cmdlet « script ». Le premier problème est que le script lui-même est un peu difficile à utiliser. Le script contient une fonction, il vous suffit de l'exécution du script ne faire quoi que ce soit. Vous devez modifier le script et ajouter les commandes nécessaires pour exécuter la fonction, ou vous avez à point source du script dans le shell, qui effectue la fonction est disponible sous la forme d'une commande globale.
Le deuxième problème est que le script inclus deux fonctions. Le premier, Get-OSInfo, est celui que je veux que les personnes à utiliser. Le second, OSInfoWorker, fait tout le travail réel. Toutefois, qui n'est pas celui que vous allez devoir exécuter directement. À l'aide de points de l'approvisionnement, il est inutile pour masquer les OSInfoWorker (ou rendez-le privé, en termes de programmeur). Rendre le script dans un module de script répondra à ces deux problèmes.
Logique de Modules
Windows PowerShell prend en charge trois types de modules : binaire, écrire des scripts et modules de manifeste. Un module binaire se compose d'une DLL générée dans Visual Studio ajoute des applets de commande, les fournisseurs et les autres éléments à l'interpréteur de commandes. Un module de script est exactement ce que : un seul script peut ajouter une ou plusieurs fonctions à l'interpréteur de commandes. Un module du manifeste peut englobent plusieurs composants, tels que les extensions binaires, scripts et ainsi de suite. Modules de script étant la plus simple créer, c'est ce que nous allons utiliser.
Il existe trois éléments requis pour un module de script :
- Il doit être un script Windows PowerShell valide, composé principalement de fonctions qui seront ajoutées à la coque.
- Il doit avoir une extension de nom de fichier .psm1, plutôt que. ps1.
- Il doit se trouver dans un dossier particulier sur votre ordinateur
Cette dernière exigence est en fait plus d'une suggestion pour des raisons de commodité. Lors de l'installation, Windows PowerShell définit une nouvelle variable d'environnement système appelée PSModulePath. Cela fonctionne bien comme variable d'environnement Path du système. Il contient les dossiers que Shell recherche automatiquement pour rechercher des modules par nom.
Il existe deux chemins de module définis par défaut. L'un est sous la hiérarchie du dossier System32. Celui-ci est destiné aux modules fourni par Microsoft. L'autre dans votre dossier de Documents et est destiné à vos propres modules. Nous allons utiliser celle-ci. Vous pouvez, bien sûr, modifier ou ajouter au PSModulePath — peut-être définir un chemin d'accès central que votre équipe utilise pour stocker les modules partagés.
Le chemin d'accès, nous allons utiliser est \[My] Documents\WindowsPowerShell\Modules. Sur Windows XP, il est intitulé Mes Documents. Dans Windows Vista et versions ultérieures, il est simplement les Documents. Le dossier WindowsPowerShell n'existe pas par défaut. Vous devrez créer un. Le sous-dossier Modules également n'existe par défaut, il vous faudra donc créer qui ainsi.
Le placement de votre module dans un des emplacements PSModulePath consiste à simplement spécifier un chemin d'accès complet et le nom de fichier lorsque vous chargez un module. Je trouve que pour convenir moins fréquemment utilisée modules, donc j'ai tendance à dire les chemins d'accès définis dans PSModulePath.
Un Module de fabrication
Je vais ajouter trois commandes vers le bas du script du mois dernier (vous pouvez télécharger le script modifié ici) :
New-Alias goi Get-OSInfo
Export-ModuleMember -function Get-OSInfo
Export-ModuleMember -alias goi
La première commande définit un alias, « pouvoirs publics indiens. » Il s'agit de ma fonction Get OSInfo. Les deux commandes ne sont plus efficaces lorsque vous les utilisez dans un module de script.
Par défaut, lorsque vous chargez un module dans le shell, chaque fonction au sein de ce module est rendue disponible. Lorsque vous utilisez Export-ModuleMember, toutefois, seuls les fonctionne — et les alias — qui sont nommés explicitement sont rendus disponibles.
Mon alias « pouvoirs publics indiens », ainsi que la fonction Get-OSInfo, doit être visible à toute personne utilisant ce module. La fonction que je n'avez pas spécifié, OSInfoWorker, sera masquée. Vous pouvez toujours utiliser n'importe quelle fonction appeler OSInfoWorker dans le module lui-même, mais il ne sera pas directement accessible, comme c'est une fonction privée.
Ces commandes ajouté, je dois attribuer le script un nom propre et le placer au bon endroit. Supposons que je choisis de nommer ce module « MyModule ». Cela signifie que le fichier de script doit passer dans \[My] Documents\WindowsPowerShell\Modules\MyModule\MyModule.psm1.
Le script doit aller dans un sous-dossier de Modules. Le sous-dossier et le fichier de script lui-même doivent porter le nom du module. Après cela, je peux exécuter MyModule du Module d'importation pour charger mon module.
Il s'agit d'un moyen facile et efficace pour distribuer des scripts à d'autres utilisateurs. Je peux inclure autant de fonctions et alias que je le souhaite dans ce même fichier. Comme il se trouve dans la zone appropriée (ou une personne est disposée à spécifier son chemin d'accès complet), il est facile d'autres utilisateurs de charger le module et utiliser ces fonctions.
.jpg)
Don Jones est le fondateur de concentré de technologie et de questions réponses sur Windows PowerShell et d'autres technologies de ConcentratedTech.com. Il est également un auteur de Nexus.Realtimepublishers.com, ce qui rend la plupart de ses livres disponibles en éditions électroniques gratuitement via son site web.
Tirez le maximum
Télécharger exemple de code associée à l'article de ce mois-ci.
Temps manque pour vous inscrire à live, exclusif, pratique atelier de trois jours des Jones co-localisé avec TechMentor printemps 2011. Visitez le site TechMentorEvents.compour plus d'informations.