- PowerShell does not offer a direct cmdlet to manipulate $env:path that would stick after the shell is closed.
- [System.Environment]::GetEnvironmentVariable() and [System.Environment]::SetEnvironmentVariable() .NET methods are the way to go about this.
- Standard PowerShell window would not work in this case, and you need to be on an elevated PowerShell window.
- You can also directly manipulate the registry key which holds system-wide environments variables [HKLM\System\CurrentControlSet\Control\Session Manager\Environment\Path]
To get the current path, you can either use .NET method or built in $ENV variable:
PS C:\> [System.Environment]::GetEnvironmentVariable('PATH')Note that, with the .NET [System.Environment], you have also the option of getting USER variable only:
C:\Program Files (x86)\AMD APP\bin\x86_64;C:\Program Files (x86)\AMD APP\bin\x86;...
PS C:\> $env:Path
C:\Program Files (x86)\AMD APP\bin\x86_64;C:\Program Files (x86)\AMD APP\bin\x86;...
PS C:\[System.Environment]::GetEnvironmentVariable('PATH','USER')
C:\Program Files (x86)\Google\google_appengine\
To add my Python Path (c:\Python\27):
PS C:\> [System.Environment]::SetEnvironmentVariable('PATH',$env:Path + ';C:\Python\27', 'MACHINE')It's important to remember that when you are trying to make system-wide changes, or sometimes even to access system data, you need to be on an elevated shell, which you can get by right clicking PowerShell launcher and choosing 'Run As Administrator'
Most of the time, PowerShell will give you hints that you need to be on an elevated shell but not always. For example, if you run the command above in a regular shell, you do not get an error. In fact, the change will seem to go through, except it won't and when you launch a new shell, you will notice that path you added is not there.
Below is an example where you do get an error if you attempt to run it in a non-elevated shell:
function get-smart {
gwmi -namespace root\wmi -class MSStorageDriver_FailurePredictStatus |
select InstanceName,PredictFailure,Reason |ft -a
}
Regular shell will 'yell' at you in red:
PS C:> get-smartgwmi : Access deniedAt line:2 char:2+ gwmi -namespace root\wmi -class MSStorageDriver_FailurePredictStatus |select In ...
Run the same function in an elevated window:
PS C:\> get-smartInstanceName PredictFailure Reason------------ -------------- ------SCSI\Disk&Ven_Hitachi&Prod_HDT721010SLA360&Rev_ST6O\5&24ba3dff&0&000000_0 False 0SCSI\Disk&Ven_&Prod_ST31500341AS\4&5ecf4f&0&020000_0 False 0By the way, that function will check the SMART status of your hard drives and tell you whether SMART expects any failure
No comments:
Post a Comment