Si vous appelez des applications natives, vous devez vous préoccuper des points suivants [Environment]::CurrentDirectory
pas à propos de PowerShell $PWD
répertoire actuel. Pour diverses raisons, PowerShell ne définit pas le répertoire de travail actuel du processus lorsque vous utilisez Set-Location ou Push-Location. Vous devez donc vous assurer de le faire si vous exécutez des applications (ou des cmdlets) qui s'attendent à ce qu'il soit défini.
Dans un script, vous pouvez faire cela :
$CWD = [Environment]::CurrentDirectory
Push-Location $MyInvocation.MyCommand.Path
[Environment]::CurrentDirectory = $PWD
## Your script code calling a native executable
Pop-Location
# Consider whether you really want to set it back:
# What if another runspace has set it in-between calls?
[Environment]::CurrentDirectory = $CWD
Il n'y a pas d'alternative infaillible à cela. Beaucoup d'entre nous insèrent une ligne dans notre fonction d'invite pour définir [Environment]::CurrentDirectory ... mais cela ne vous aide pas lorsque vous changez l'emplacement de votre ordinateur. sur un script.
Deux remarques sur la raison pour laquelle ce paramètre n'est pas défini automatiquement par PowerShell :
- PowerShell peut être multithreadé. Vous pouvez avoir plusieurs espaces d'exécution (voir RunspacePool, et le module PSThreadJob) fonctionnant simultanément dans un seul processus. Chaque espace d'exécution possède son propre
$PWD
le répertoire de travail actuel, mais il n'y a qu'un seul processus, et un seul environnement.
- Même lorsque vous êtes en monofilière,
$PWD
n'est pas toujours un CurrentDirectory légal (vous pouvez par exemple utiliser le CD dans le fournisseur de registre).
Si vous voulez le mettre dans votre prompt (qui ne s'exécutera que dans l'espace d'exécution principal, en mode monofilaire), vous devez utiliser :
[Environment]::CurrentDirectory = Get-Location -PSProvider FileSystem