Powershell gourous, veuillez préciser la portée des variables en fonction de

Variables au sein de la fonction sont locales à cette étendue, à moins que vous point l'invocation du nom de la fonction. Lorsque vous dot source d'un script, le script de niveau supérieur variables sont effectivement importées dans le champ d'application actuel avec les définitions de fonction par exemple:

PS> '$scriptvar = 2; function my-f { ${my-f-var} = 2 }' > my-f-script.ps1
PS> Remove-Variable scriptvar, my-f-var
Remove-Variable : Cannot find a variable with name 'scriptvar'.
Remove-Variable : Cannot find a variable with name 'my-f-var'.
PS> . .\my-f-script.ps1
PS> $scriptvar
2
PS> ${my-f-var}
PS>

Notez que ${ma-f-var} n'est pas défini dans la portée locale. Cependant, si je " dot " l'invocation de la fonction de son contenu sont exécutés dans le champ d'application actuel par exemple:

PS> . my-f
PS> ${my-f-var}
2

Dans ce cas, la variable définie dans la fonction est définie dans le courant (l'invocation) champ d'application en raison de la " dot " utilisé pour l'appeler.

Un couple de points de plus: vous pouvez accéder à des variables à différents domaines en utilisant soit Get-Variable -scope ou le plus pratique (si moins souple) mondial, script, locales et privées des modificateurs. Lorsque vous accédez à une variable dans une fonction où la variable est définie dans une étendue supérieure, vous pouvez lire c'est très bien. Mais quand vous le mettez, PowerShell fait essentiellement une "copie à l'écriture" de la variable de la création d'une nouvelle copie de l'étendue de cette fonction vers le bas (c'est à dire pour les autres fonctions qu'il appelle). Si vous voulez vraiment modifier plus d'étendue variable, vous pouvez utiliser $global:Foo ou $script:Foo de modifier à ces étendues.

La local champ d'application est très pratique si vous voulez éviter, par inadvertance, à l'aide d'une variable définie à l'extérieur de votre fonction. Un autre MVP apporté ce jusqu'à la dernière MVP summit, et il semble comme un de ces "meilleures pratiques" des conseils. Voici le scénario:

PS> $foo = 'bad'
PS> function testscope { $fooo = 'good'; "The value of `$fooo is $foo" }
PS> testscope
The value of $fooo is bad

Noter que dans ce cas l'utilisation de $foo à l'intérieur de la fonction est une faute de frappe mais comme par hasard il y a une variable par la faute de frappe avait nom. Ce n'était pas l'intention de la fonction et il ne fonctionne pas correctement bien qu'il est difficile de voir dans ce cas. Ci-dessous, nous pouvons utiliser la local spécificateur assurez-vous que la fonction de recherche uniquement dans les locaux de la portée de la variable. Il ne le trouve pas en raison de la faute de frappe, mais au moins l'erreur est un peu plus facile à repérer maintenant.

PS> function testscope { $fooo = 'good'; "The value of `$fooo is $local:foo" }
PS> testscope
The value of $fooo is

La private champ d'application est utile lorsque vous ne voulez pas que certaines variables soient visibles pour les autres fonctions de vos appels de fonction.