82 votes

Où mettre les scripts PowerShell ?

(Je n'arrive pas à croire que je pose cette question, mais je suis à court de matière grise pour la journée).

Je viens d'écrire mon premier script PowerShell sérieux, et j'en suis très content. Je prévois de l'utiliser tous les jours ou presque. Je veux être capable de l'appeler depuis la ligne de commande Posh. Je lui donnerai un nom de type verbe-nom, mais pour l'instant c'est un simple .ps1 et pas une de ces fonctions avancées fantaisistes qui prennent des paramètres et autres.

Alors où doit-il aller et comment puis-je l'appeler depuis une ligne de commande Posh ? Je prévois d'en écrire plus ! Où doivent-ils aller ?

  • Devrait-il s'agir d'une fonction dans mon profil ?
  • Doit-il aller sur mon chemin ?
  • Doit-il être placé dans un PSMODULEPATH ? Quel genre de choses y vont de toute façon ? Est-ce qu'il y a récurrence ou est-ce que c'est juste comme le PATH normal ?

Où mettez-vous tous vos scripts PowerShell et comment les organisez-vous ? J'ai beaucoup d'expérience dans la création d'outils C# et C++ et je sais comment les nommer et où les placer. Et à l'autre extrême, j'ai fait beaucoup de fichiers .bat merdiques qui sont généralement autonomes ou empilés dans un tas dans un dossier. Mais PowerShell semble être très différent. Vous pouvez faire des choses de type fichier .bat très rapidement, ou vous pouvez construire des bibliothèques et des services sophistiqués avec lui.

J'aimerais vraiment avoir des idées sur la façon dont je devrais organiser ces choses avant de commencer. Il est évident que tout le monde est différent, alors j'espère avoir quelques discussions. Merci.

30voto

Jay Bazuzi Points 20462

Je mets mes scripts personnels dans le même dossier que mon profil. Je peux alors les sauvegarder et les versionner ensemble. Mon profil commence par :

$ProfileRoot = (Split-Path -Parent $MyInvocation.MyCommand.Path)
$env:path += ";$ProfileRoot"

3 votes

Utiliser $script:MyInvocation.MyCommand.Path, voir chemin source d'un script en cours d'exécution . Vous rencontrez des problèmes avec les appelants imbriqués, même avec le profil script, par exemple, j'ai une fonction d'aide pour recharger votre profil (après des modifications de fonctions/variables) mais je saute toutes les init uniques (comme le chargement des assemblages .NET).

1 votes

Ce script est-il idempotent ? Ou bien vous réappliqueriez potentiellement le même répertoire à chaque fois que vous l'exécutez ?

21voto

stej Points 14257

Mes recommandations : - Stockez le script dans un répertoire comme vous le souhaitez, par exemple c : \posh - Ajouter le répertoire à $env:path

$env:path += ";c:\posh"

Cela garantit que vous pouvez être dans un autre répertoire, disons c : \windows mais vous pouvez appeler le script

[c:\windows] > sampl[TAB] # it expands the name of file to sample.ps1, then hit enter

Si votre fichier sample.ps1 contient des définitions de fonctions et que vous l'importez à chaque fois, alors j'envisagerais d'ajouter cette ligne à votre fichier $profile

. c:\posh\sample.ps1

En ce qui concerne l'organisation des script... juste plusieurs répertoires selon le but des script :) Personnel, dev, externe (téléchargé), échantillons,...

1 votes

C'est la réponse la plus directe, et elle fonctionne. De plus, elle ne perturbe pas votre organisation personnelle. En ce qui concerne les sauvegardes, etc. Celles-ci sont très personnalisées, et donc c'est au cas par cas où vous devriez stocker les scripts pour la sauvegarde, etc. De plus, la "sauvegarde" n'est pas vraiment pertinente pour la question :).

19voto

Andy Schneider Points 4118

Avec la V2, vous pouvez créer un répertoire de modules dans le répertoire WindowsPowerShell où se trouve votre profil. PS va automatiquement chercher dans ce répertoire pour charger les modules lorsque vous exécutez import-module. J'ai créé un répertoire "scripts" sous WindowsPowerShell également qui est un répertoire frère de Modules.

J'utilise mon profil pour définir certains répertoires en utilisant des variables avec le code suivant :

PS>  cat $Profile
$scripts = "$(split-path $profile)\Scripts"
$modules = "$(split-path $profile)\Modules"
$docs    =  $(resolve-path "$Env:userprofile\documents")
$desktop =  $(resolve-path "$Env:userprofile\desktop")

PS> cat variable:\scripts
C:\Users\andy.schneider\Documents\WindowsPowerShell\Scripts

PS>  cat variable:\modules
C:\Users\andy.schneider\Documents\WindowsPowerShell\Modules

0 votes

C'est aussi ce que je fais. Bien que j'ai aussi un répertoire "Libraries" avec scripts que mon profil exécute automatiquement pour définir les fonctions globales. J'ai fait cela dans PowerShell v1, je vais probablement remplacer tout cela par des modules à terme.

10voto

Andrew Jackson Points 274

C'est ce que je fais :

note : remplacez "ModuleName" par quelque chose de significatif.

Créez un module et enregistrez-le dans le dossier global des modules sous le nom de " C:\Windows\System32\WindowsPowerShell\v1.0\Modules\ModuleName\ModuleName.psm1 ". Par exemple :

function global:FancyFunction() {
   # do something interesting here.
}

Export-ModuleMember -function FancyFunction 

Ouvrez votre profil powershell et ajoutez la ligne suivante pour vous assurer que votre module est chargé chaque fois que vous démarrez une session powershell :

Import-Module ModuleName -Force

Vous pouvez facilement trouver votre profil powershell en tapant :

notepad $profile

Lorsque vous ouvrez une nouvelle session powershell, vous devriez pouvoir appeler votre fonction depuis la console ou depuis d'autres scripts sans avoir à faire quoi que ce soit d'autre.

2voto

maciejW Points 92

Il existe une variable exportée dans le module PowerShellGet utilisé dans powershell 7.1.

$PSGetPath

il a 4 propriétés

AllUsersModules    : C:\Program Files\PowerShell\Modules
AllUsersScripts    : C:\Program Files\PowerShell\Scripts
CurrentUserModules : C:\Users\username\Documents\PowerShell\Modules
CurrentUserScripts : C:\Users\username\Documents\PowerShell\Scripts

vous pourriez utiliser un de ces emplacements script. Install-Script les utilise également.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X