Google

2014-01-19

Updating Environment Variables

I installed Python 2.7 on my computer, but install path was not added to environment variables. A couple of quick notes on doing this with PowerShell:

  • 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')
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;...

Note that, with the .NET [System.Environment], you have also the option of getting USER variable only:

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-smart
gwmi : Access denied 
At line:2 char:2
+     gwmi -namespace root\wmi -class MSStorageDriver_FailurePredictStatus |select In ...
Run the same function in an elevated window:

PS C:\> get-smart

InstanceName                                                              PredictFailure Reason
------------                                                              -------------- ------
SCSI\Disk&Ven_Hitachi&Prod_HDT721010SLA360&Rev_ST6O\5&24ba3dff&0&000000_0          False      0
SCSI\Disk&Ven_&Prod_ST31500341AS\4&5ecf4f&0&020000_0                               False      0

By the way, that function will check the SMART status of your hard drives and tell you whether SMART expects any failure

No comments: