Définition des variables d'environnement Windows PowerShell


608

J'ai découvert que la définition de la variable d'environnement PATH affecte uniquement l'ancienne invite de commande. PowerShell semble avoir différents paramètres d'environnement. Comment modifier les variables d'environnement pour PowerShell (v1)?

Remarque:

Je veux rendre mes modifications permanentes, donc je n'ai pas à les définir à chaque fois que j'exécute PowerShell. PowerShell a-t-il un fichier de profil? Quelque chose comme le profil Bash sur Unix?


1
J'aimerais avoir un profil central situé sur un partage de fichiers. La synchronisation est pénible. Création d'un profil de stub avec. \\ ordinateur \ partage \ chemin \ Profile.ps1 ressemble à un kludge (essayez Notepad $ Profile). Ce serait bien s'il y avait un moyen de changer définitivement la variable automatique $ Profile.
Nathan Hartley

5
Non, l'environnement PATH n'affecte pas également l'invite de commande powershell. Ce qui diffère cependant, c'est que PowerShell n'accepte pas les chemins entre guillemets. Solution: supprimez toutes les guillemets ( ") dans la variable d'environnement path
Nilzor

3
SI VOUS ARRIVEZ ICI POUR PS> v1 ... Suite au commentaire de Nilzor ci-dessus: Utilisez ceci pour supprimer tous les "des chemins dans la variable d'environnement PATH pour votre session:$($Env:PATH).Split(';') | %{ $str += "$($_.Trim('"'));" }; $Env:PATH=$str
d3r3kk

Réponses:


479

La modification des variables d'environnement réelles peut être effectuée à l'aide des env: namespace / driveinformations. Par exemple, ce code mettra à jour la variable d'environnement path:

$env:Path = "SomeRandomPath";             (replaces existing path) 
$env:Path += ";SomeRandomPath"            (appends to existing path)

Il existe des moyens de rendre les paramètres d'environnement permanents, mais si vous les utilisez uniquement à partir de PowerShell, il est probablement beaucoup mieux d'utiliser votre profil pour lancer les paramètres. Au démarrage, PowerShell exécutera tous les fichiers .ps1 qu'il trouve dans le WindowsPowerShellrépertoire sous le dossier Mes documents. En général, vous avez déjà un fichier profile.ps1 . Le chemin sur mon ordinateur est

C:\Users\JaredPar\Documents\WindowsPowerShell\profile.ps1

38
$ profile est une variable automatique qui pointe vers votre profil utilisateur pour tous les hôtes PowerShell.
JasonMArcher

16
Notez que (split-path $ profile) (pour obtenir le dossier contenant) peut contenir plusieurs fichiers de profil: profile.ps1 doit être chargé par tous les hôtes, <host-name> _profile.ps1 uniquement par l'hôte spécifié. Pour PowerShell.exe (hôte de console), il s'agit de Microsoft.PowerShell_profile.ps1.
Richard

10
Que faire si je n'ai pas de dossier WindowsPowerShell dans mes documents? Dois-je créer le dossier et le fichier? Que dois-je mettre dans le fichier si je veux ajouter C:\path\to\file.extaux variables d'environnement? EDIT: l'a déjà trouvé. La réponse est oui, créez-le. Le fichier doit être constitué de 1 ligne: $env:path += ;C:\path\to\file.ext".
Lewistrick

7
@Lewistrick Vous n'avez pas de profil par défaut. J'ai suivi ces instructions pour en créer un: howtogeek.com/50236/customizing-your-powershell-profile
MikeB

16
Soyez prudent en faisant cela - cela encombrera votre chemin existant. $env:Path = "SomeRandomPath"; Au lieu de cela - voir @mloskot, ci-dessous.
John Mark

626

Si, à un moment donné au cours d'une session PowerShell, vous devez ajouter temporairement à la variable d'environnement PATH, vous pouvez le faire de cette façon:

$env:Path += ";C:\Program Files\GnuWin32\bin"

4
+1 :: Ce one-liner est assez efficace pour les invocations basées sur la session comme avec mingw ... IE $ env: PATH + = "; c: \ MinGW \ msys \ 1.0 \ bin" ^ {certains bin mingw ... }
Eddie B

2
et comment supprimer un chemin?
Becko

11
Si vous avez besoin que votre chemin soit appelé avant celui standard, insérez-le au début $env:Path = "C:\MyPath;$env:Path"
Michael Freidgeim

4
**** N'oubliez pas le point-virgule au début de la chaîne ajoutée, comme le montre le commentaire de @Kevin. Ceci est assez évident, mais peut être manqué si vous copiez / collez simplement le code dans la réponse et que vous n'aviez pas de point-virgule à la fin du chemin existant. J'essaierai de soumettre une modification.
Matt Goodrich

1
@MattGoodrich J'ai revenir à la révision précédente
Cœur

278

Vous pouvez également modifier les variables d'environnement utilisateur / système de manière permanente (c'est-à-dire qu'elles seront persistantes lors des redémarrages du shell) avec les éléments suivants:

Modifier une variable d'environnement système

[Environment]::SetEnvironmentVariable
     ("Path", $env:Path, [System.EnvironmentVariableTarget]::Machine)

Modifier une variable d'environnement utilisateur

[Environment]::SetEnvironmentVariable
     ("INCLUDE", $env:INCLUDE, [System.EnvironmentVariableTarget]::User)

Utilisation des commentaires - ajouter à la variable d'environnement système

[Environment]::SetEnvironmentVariable(
    "Path",
    [Environment]::GetEnvironmentVariable("Path", [EnvironmentVariableTarget]::Machine) + ";C:\bin",
    [EnvironmentVariableTarget]::Machine)

Une solution basée sur les chaînes est également possible si vous ne voulez pas écrire de types

[Environment]::SetEnvironmentVariable("Path", $env:Path + ";C:\bin", "Machine")

6
Ceci est très utile pour les systèmes à accès restreint.
h0tw1r3

14
@AndresRiofrio, Oui, c'est permanent. Utilisation: [Environment]::SetEnvironmentVariable("Path", $env:Path + ";C:\bin", [EnvironmentVariableTartget::Machine) vous ne verrez pas le résultat de cette modification tant que vous n'aurez pas démarré une nouvelle session PowerShell. Autrement dit, si vous inspectez $ env: Path immédiatement après avoir exécuté cette commande, vous verrez ce que $ env: Path était avant la commande. Pour mettre à jour, fermer et ouvrir le shell ou démarrer une nouvelle session.
FLGMwt

7
@FLGMwt vous avez une faute de frappe, correcte est: [Environment] :: SetEnvironmentVariable ("Path", $ env: Path + "; C: \ bin", [EnvironmentVariableTarget] :: Machine)
enthousiaste le

10
Vous pouvez écrire la chaîne "Machine" ou "Utilisateur" au lieu de l'énumération .NET entière. De Technet .
bouvierr

3
Je pense que cette réponse devrait également démontrer l'utilisation pour définir la variable utilisateur, comme ceci[Environment]::SetEnvironmentVariable("Path", [Environment]::GetEnvironmentVariable("Path", "User") + ";C:\bin", "User")
Saito

63

À partir de l'invite PowerShell:

setx PATH "$env:path;\the\directory\to\add" -m

Vous devriez alors voir le texte:

SUCCESS: Specified value was saved.

Redémarrez votre session et la variable sera disponible. setxpeut également être utilisé pour définir des variables arbitraires. Tapez setx /?à l'invite de documentation.

Avant de jouer avec votre chemin de cette manière, assurez-vous d'enregistrer une copie de votre chemin existant en le faisant $env:path >> a.outdans une invite PowerShell.


5
Semble fonctionner uniquement lors de «l'exécution en tant qu'administrateur», et ne prend ensuite effet que pour les consoles PowerShell «en tant qu'administrateur», et non celles qui s'exécutent régulièrement.
matanster


12
Aïe - vient d'être atteint par la limite de 1024 caractères de setx; Heureusement, j'ai suivi les conseils pour enregistrer la valeur existante de $ end: Path. Juste quelque chose à savoir: superuser.com/questions/387619/…
Jonno

3
Pourquoi ne pas définir d' $env:PATHabord, puis setx /m PATH "$env:PATH"pour qu'il s'applique localement et globalement sans redémarrage du shell?
tresf

1
Agréable! Bien que setx ne soit pas une applet de commande native, c'est toujours une alternative bien meilleure et facilement oubliée à ces appels répugnants .NET Framework! Il est déconcertant que même Powershell 7 ne soit toujours pas livré avec une applet de commande officielle pour persister les envvars. Quoi. Se sent comme une fonctionnalité qui devrait avoir la parité avec «ls».
Jonas

27

Comme la réponse de JeanT , je voulais une abstraction autour de l'ajout au chemin. Contrairement à la réponse de JeanT, j'en avais besoin pour fonctionner sans interaction avec l'utilisateur. Autre comportement que je recherchais:

  • Mises à jour $env:Pathpour que le changement prenne effet dans la session en cours
  • Persiste le changement de variable d'environnement pour les sessions futures
  • N'ajoute pas de chemin en double alors que le même chemin existe déjà

Au cas où cela serait utile, le voici:

function Add-EnvPath {
    param(
        [Parameter(Mandatory=$true)]
        [string] $Path,

        [ValidateSet('Machine', 'User', 'Session')]
        [string] $Container = 'Session'
    )

    if ($Container -ne 'Session') {
        $containerMapping = @{
            Machine = [EnvironmentVariableTarget]::Machine
            User = [EnvironmentVariableTarget]::User
        }
        $containerType = $containerMapping[$Container]

        $persistedPaths = [Environment]::GetEnvironmentVariable('Path', $containerType) -split ';'
        if ($persistedPaths -notcontains $Path) {
            $persistedPaths = $persistedPaths + $Path | where { $_ }
            [Environment]::SetEnvironmentVariable('Path', $persistedPaths -join ';', $containerType)
        }
    }

    $envPaths = $env:Path -split ';'
    if ($envPaths -notcontains $Path) {
        $envPaths = $envPaths + $Path | where { $_ }
        $env:Path = $envPaths -join ';'
    }
}

Consultez mon essentiel pour la Remove-EnvPathfonction correspondante .


16

Bien que la réponse actuellement acceptée fonctionne dans le sens où la variable de chemin d'accès est mise à jour en permanence à partir du contexte de PowerShell, elle ne met pas à jour la variable d'environnement stockée dans le registre Windows.

Pour y parvenir, vous pouvez bien sûr également utiliser PowerShell:

$oldPath=(Get-ItemProperty -Path 'Registry::HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Environment' -Name PATH).Path

$newPath=$oldPath+’;C:\NewFolderToAddToTheList\’

Set-ItemProperty -Path 'Registry::HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Environment' -Name PATH Value $newPath

Plus d'informations sont dans le billet de blog Utilisez PowerShell pour modifier votre chemin environnemental

Si vous utilisez des extensions de communauté PowerShell, la commande appropriée pour ajouter un chemin au chemin de variable d'environnement est:

Add-PathVariable "C:\NewFolderToAddToTheList" -Target Machine

12

Toutes les réponses suggérant un changement permanent ont le même problème: elles cassent la valeur du registre de chemin.

SetEnvironmentVariabletransforme la REG_EXPAND_SZvaleur %SystemRoot%\system32 en REG_SZvaleur de C:\Windows\system32.

Toutes les autres variables du chemin sont également perdues. Ajouter de nouveaux en utilisant %myNewPath%ne fonctionnera plus.

Voici un script Set-PathVariable.ps1que j'utilise pour résoudre ce problème:

 [CmdletBinding(SupportsShouldProcess=$true)]
 param(
     [parameter(Mandatory=$true)]
     [string]$NewLocation)

 Begin
 {

 #requires –runasadministrator

     $regPath = "SYSTEM\CurrentControlSet\Control\Session Manager\Environment"
     $hklm = [Microsoft.Win32.Registry]::LocalMachine

     Function GetOldPath()
     {
         $regKey = $hklm.OpenSubKey($regPath, $FALSE)
         $envpath = $regKey.GetValue("Path", "", [Microsoft.Win32.RegistryValueOptions]::DoNotExpandEnvironmentNames)
         return $envPath
     }
 }

 Process
 {
     # Win32API error codes
     $ERROR_SUCCESS = 0
     $ERROR_DUP_NAME = 34
     $ERROR_INVALID_DATA = 13

     $NewLocation = $NewLocation.Trim();

     If ($NewLocation -eq "" -or $NewLocation -eq $null)
     {
         Exit $ERROR_INVALID_DATA
     }

     [string]$oldPath = GetOldPath
     Write-Verbose "Old Path: $oldPath"

     # Check whether the new location is already in the path
     $parts = $oldPath.split(";")
     If ($parts -contains $NewLocation)
     {
         Write-Warning "The new location is already in the path"
         Exit $ERROR_DUP_NAME
     }

     # Build the new path, make sure we don't have double semicolons
     $newPath = $oldPath + ";" + $NewLocation
     $newPath = $newPath -replace ";;",""

     if ($pscmdlet.ShouldProcess("%Path%", "Add $NewLocation")){

         # Add to the current session
         $env:path += ";$NewLocation"

         # Save into registry
         $regKey = $hklm.OpenSubKey($regPath, $True)
         $regKey.SetValue("Path", $newPath, [Microsoft.Win32.RegistryValueKind]::ExpandString)
         Write-Output "The operation completed successfully."
     }

     Exit $ERROR_SUCCESS
 }

J'explique le problème plus en détail dans un article de blog .


Devrait-il s'agir de: $ newPath = $ newPath -replace ";;", ";" ?
Joe Johnston

8

Cela définit le chemin de la session en cours et invite l'utilisateur à l'ajouter de façon permanente:

function Set-Path {
    param([string]$x)
    $Env:Path+= ";" +  $x
    Write-Output $Env:Path
    $write = Read-Host 'Set PATH permanently ? (yes|no)'
    if ($write -eq "yes")
    {
        [Environment]::SetEnvironmentVariable("Path",$env:Path, [System.EnvironmentVariableTarget]::User)
        Write-Output 'PATH updated'
    }
}

Vous pouvez ajouter cette fonction à votre profil par défaut, ( Microsoft.PowerShell_profile.ps1), généralement situé dans %USERPROFILE%\Documents\WindowsPowerShell.


6

En s'appuyant sur la réponse de @Michael Kropat, j'ai ajouté un paramètre pour ajouter le nouveau chemin à la PATHvariable existante et une vérification pour éviter l'ajout d'un chemin inexistant:

function Add-EnvPath {
    param(
        [Parameter(Mandatory=$true)]
        [string] $Path,

        [ValidateSet('Machine', 'User', 'Session')]
        [string] $Container = 'Session',

        [Parameter(Mandatory=$False)]
        [Switch] $Prepend
    )

    if (Test-Path -path "$Path") {
        if ($Container -ne 'Session') {
            $containerMapping = @{
                Machine = [EnvironmentVariableTarget]::Machine
                User = [EnvironmentVariableTarget]::User
            }
            $containerType = $containerMapping[$Container]

            $persistedPaths = [Environment]::GetEnvironmentVariable('Path', $containerType) -split ';'
            if ($persistedPaths -notcontains $Path) {
                if ($Prepend) {
                    $persistedPaths = ,$Path + $persistedPaths | where { $_ }
                    [Environment]::SetEnvironmentVariable('Path', $persistedPaths -join ';', $containerType)
                }
                else {
                    $persistedPaths = $persistedPaths + $Path | where { $_ }
                    [Environment]::SetEnvironmentVariable('Path', $persistedPaths -join ';', $containerType)
                }
            }
        }

        $envPaths = $env:Path -split ';'
        if ($envPaths -notcontains $Path) {
            if ($Prepend) {
                $envPaths = ,$Path + $envPaths | where { $_ }
                $env:Path = $envPaths -join ';'
            }
            else {
                $envPaths = $envPaths + $Path | where { $_ }
                $env:Path = $envPaths -join ';'
            }
        }
    }
}

5

Comme Jonathan Leaders l'a mentionné ici , il est important d'exécuter la commande / le script élevé pour pouvoir modifier les variables d'environnement pour 'machine' , mais l'exécution de certaines commandes élevées ne doit pas être effectuée avec les extensions de communauté, donc j'aimerais pour modifier et étendre la réponse de JeanT d' une manière, que les variables de machine changeantes peuvent également être effectuées même si le script lui-même n'est pas exécuté de manière élevée:

function Set-Path ([string]$newPath, [bool]$permanent=$false, [bool]$forMachine=$false )
{
    $Env:Path += ";$newPath"

    $scope = if ($forMachine) { 'Machine' } else { 'User' }

    if ($permanent)
    {
        $command = "[Environment]::SetEnvironmentVariable('PATH', $env:Path, $scope)"
        Start-Process -FilePath powershell.exe -ArgumentList "-noprofile -command $Command" -Verb runas
    }

}

5

La plupart des réponses ne concernent pas l' UAC . Cela couvre les problèmes UAC.

Installez d'abord les extensions de communauté PowerShell: choco install pscxvia http://chocolatey.org/ (vous devrez peut-être redémarrer votre environnement shell).

Activez ensuite pscx

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser #allows scripts to run from the interwebs, such as pcsx

Ensuite, utilisez Invoke-Elevated

Invoke-Elevated {Add-PathVariable $args[0] -Target Machine} -ArgumentList $MY_NEW_DIR

4

Ma suggestion est celle-ci:

J'ai testé cela pour l'ajouter C:\oracle\x64\binà la variable d'environnement en Pathpermanence et cela fonctionne bien.

$ENV:PATH

La première consiste simplement à faire:

$ENV:PATH=”$ENV:PATH;c:\path\to\folder

Mais ce changement n'est pas permanent. $env:pathreviendra par défaut à ce qu'il était avant dès que vous fermez votre terminal PowerShell et que vous le rouvrez à nouveau. C'est parce que vous avez appliqué la modification au niveau de la session et non au niveau source (qui est le niveau du registre). Pour afficher la valeur globale de $env:path, procédez comme suit:

Get-ItemProperty -Path Registry::HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Environment -Name PATH

Ou plus précisément:

(Get-ItemProperty -Path Registry::HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Environment -Name PATH).path

Maintenant, pour changer cela, nous capturons d'abord le chemin d'origine qui doit être modifié:

$oldpath = (Get-ItemProperty -Path Registry::HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Environment -Name PATH).path

Nous définissons maintenant à quoi devrait ressembler le nouveau chemin. Dans ce cas, nous ajoutons un nouveau dossier:

$newpath = $oldpath;c:\path\to\folder

Remarque: assurez-vous que l' $newpathapparence vous convient. Sinon, vous pourriez endommager votre système d'exploitation.

Appliquez maintenant la nouvelle valeur:

Set-ItemProperty -Path Registry::HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Environment -Name PATH -Value $newPath

Maintenant, vérifiez une dernière fois que cela ressemble à ce que vous attendez:

(Get-ItemProperty -Path Registry::HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Environment -Name PATH).Path

Vous pouvez maintenant redémarrer votre terminal PowerShell (ou même redémarrer la machine) et voir qu'il ne revient pas à son ancienne valeur.

Notez que l'ordre des chemins peut changer pour qu'il soit dans l'ordre alphabétique, alors assurez-vous de vérifier toute la ligne. Pour le rendre plus facile, vous pouvez diviser la sortie en lignes en utilisant le point-virgule comme délimiteur:

($env:path).split(“;”)

3

Ouvrez PowerShell et exécutez:

[Environment]::SetEnvironmentVariable("PATH", "$ENV:PATH;<path to exe>", "USER")

1

Dans PowerShell, on peut accéder au répertoire des variables d'environnement en tapant:

Set-Location Env:

Cela vous amènera au répertoire Env:>. Depuis ce répertoire:

Pour voir toutes les variables d'environnement, tapez:

Env:\> Get-ChildItem

Pour voir une variable d'environnement spécifique, tapez:

Env:\> $Env:<variable name>, e.g. $Env:Path

Pour définir une variable d'environnement, tapez:

Env:\> $Env:<variable name> = "<new-value>", e.g. $Env:Path="C:\Users\"

Pour supprimer une variable d'environnement, tapez:

Env:\> remove-item Env:<variable name>, e.g. remove-item Env:SECRET_KEY

Vous trouverez plus d'informations dans A propos des variables d'environnement .


0

J'ai essayé d'optimiser un peu le code de SBF et Michael pour le rendre plus compact.

Je m'appuie sur la contrainte de type de PowerShell où il convertit automatiquement les chaînes en valeurs énumérées, donc je n'ai pas défini le dictionnaire de recherche.

J'ai également sorti le bloc qui ajoute le nouveau chemin à la liste en fonction d'une condition, de sorte que le travail soit effectué une fois et stocké dans une variable pour être réutilisé.

Il est ensuite appliqué en permanence ou simplement à la Session en fonction du $PathContainerparamètre.

Nous pouvons mettre le bloc de code dans une fonction ou un fichier ps1 que nous appelons directement à partir de l'invite de commande. Je suis allé avec DevEnvAddPath.ps1.

param(
    [Parameter(Position=0,Mandatory=$true)][String]$PathChange,

    [ValidateSet('Machine', 'User', 'Session')]
    [Parameter(Position=1,Mandatory=$false)][String]$PathContainer='Session',
    [Parameter(Position=2,Mandatory=$false)][Boolean]$PathPrepend=$false
)

[String]$ConstructedEnvPath = switch ($PathContainer) { "Session"{${env:Path};} default{[Environment]::GetEnvironmentVariable('Path', $containerType);} };
$PathPersisted = $ConstructedEnvPath -split ';';

if ($PathPersisted -notcontains $PathChange) {
    $PathPersisted = $(switch ($PathPrepend) { $true{,$PathChange + $PathPersisted;} default{$PathPersisted + $PathChange;} }) | Where-Object { $_ };

    $ConstructedEnvPath = $PathPersisted -join ";";
}

if ($PathContainer -ne 'Session') 
{
    # Save permanently to Machine, User
    [Environment]::SetEnvironmentVariable("Path", $ConstructedEnvPath, $PathContainer);
}

# Update the current session
${env:Path} = $ConstructedEnvPath;

Je fais quelque chose de similaire pour un DevEnvRemovePath.ps1.

param(
    [Parameter(Position=0,Mandatory=$true)][String]$PathChange,

    [ValidateSet('Machine', 'User', 'Session')]
    [Parameter(Position=1,Mandatory=$false)][String]$PathContainer='Session'
)

[String]$ConstructedEnvPath = switch ($PathContainer) { "Session"{${env:Path};} default{[Environment]::GetEnvironmentVariable('Path', $containerType);} };
$PathPersisted = $ConstructedEnvPath -split ';';

if ($PathPersisted -contains $PathChange) {
    $PathPersisted = $PathPersisted | Where-Object { $_ -ne $PathChange };

    $ConstructedEnvPath = $PathPersisted -join ";";
}

if ($PathContainer -ne 'Session') 
{
    # Save permanently to Machine, User
    [Environment]::SetEnvironmentVariable("Path", $ConstructedEnvPath, $PathContainer);
}

# Update the current session
${env:Path} = $ConstructedEnvPath;

Jusqu'à présent, ils semblent fonctionner.


0

Seules les réponses qui poussent la valeur dans le Registre affectent une modification permanente (de sorte que la majorité des réponses sur ce fil, y compris la réponse acceptée, n'affectent pas définitivement le Path).

La fonction suivante fonctionne pour les types Path/ PSModulePathet User/ System. Il ajoutera également le nouveau chemin d'accès à la session en cours par défaut.

function AddTo-Path {
    param ( 
        [string]$PathToAdd,
        [Parameter(Mandatory=$true)][ValidateSet('System','User')][string]$UserType,
        [Parameter(Mandatory=$true)][ValidateSet('Path','PSModulePath')][string]$PathType
    )

    # AddTo-Path "C:\XXX" "PSModulePath" 'System' 
    if ($UserType -eq "System" ) { $RegPropertyLocation = 'HKLM:\System\CurrentControlSet\Control\Session Manager\Environment' }
    if ($UserType -eq "User"   ) { $RegPropertyLocation = 'HKCU:\Environment' } # also note: Registry::HKEY_LOCAL_MACHINE\ format
    $PathOld = (Get-ItemProperty -Path $RegPropertyLocation -Name $PathType).$PathType
    "`n$UserType $PathType Before:`n$PathOld`n"
    $PathArray = $PathOld -Split ";" -replace "\\+$", ""
    if ($PathArray -notcontains $PathToAdd) {
        "$UserType $PathType Now:"   # ; sleep -Milliseconds 100   # Might need pause to prevent text being after Path output(!)
        $PathNew = "$PathOld;$PathToAdd"
        Set-ItemProperty -Path $RegPropertyLocation -Name $PathType -Value $PathNew
        Get-ItemProperty -Path $RegPropertyLocation -Name $PathType | select -ExpandProperty $PathType
        if ($PathType -eq "Path") { $env:Path += ";$PathToAdd" }                  # Add to Path also for this current session
        if ($PathType -eq "PSModulePath") { $env:PSModulePath += ";$PathToAdd" }  # Add to PSModulePath also for this current session
        "`n$PathToAdd has been added to the $UserType $PathType"
    }
    else {
        "'$PathToAdd' is already in the $UserType $PathType. Nothing to do."
    }
}

# Add "C:\XXX" to User Path (but only if not already present)
AddTo-Path "C:\XXX" "User" "Path"

# Just show the current status by putting an empty path
AddTo-Path "" "User" "Path"
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.