I'm using settings sync between multiple windows pc with different usernames.
Some settings with path such as vim.autoSwitchInputMethod.obtainIMCmd might be C:/Users/myname/im-select.exe. However it cannot work if I replace the value to ~/im-select.exe or $HOME/im-select.exe or ${env:HOME}/im-select.exe.
So how should I set the value to make it work among all different pcs? Or how to make vscode to read environment variables ?
Related
I have started using VSCODE for editing and running scripts.
If I run VSCODE as admin, I cannot access files on a network drive (mapped or otherwise).
If I don't run VSCODE as admin I cannot execute the PS scripts I need to.
Has anyone experienced something similar, or found a work around?
Since the Administrator account doesn't have the drive mappings your user account has, you can try accessing the Universal Naming Convention (UNC) path to the network resources/shares directly.
Format
\\<server-hostname-or-IP>\<share-name>\<directory-name>
Examples
\\server1\c$
\\server2\share\foo\bar
If you don't know the UNC paths for the mapped drives, run net use from a cmd.exe prompt under your user (not admin) account context. The UNC paths fall under the Remote column heading in the output, and should resemble the format outlined above.
Helpful Links
UNC paths
Net use
I have run into a couple cases where I am trying to use a command via command line, but the command is not recognized. I have narrowed it down to an issue with environment variables. In each case, the variable is present when I retrieve the variable with the underlying C# method, but not with the shorthand, $env:myVariable
For example, if I retrieve the variable like this, I will get a value.
[Environment]::GetEnvironmentVariable('ChocolateyInstall', 'Machine')
But, if I retrieve the variable like this, nothing is returned
$env:ChocolateyInstall
I then have to do something like this to to get my command to work.
$env:ChocolateyInstall = [Environment]::GetEnvironmentVariable('ChocolateyInstall', 'Machine')
I have not been able to find a good explanation as to why I have to do this. I've looked at this documentation, but nothing stands out to me. Ideally, I would like to install a CLI and then not have to deal with checking for and assigning environment variables for the command to work.
When opening a PowerShell session, all permanently stored environment variables1 will be loaded into the Environment drive (Env:) of this current session (source):
The Environment drive is a flat namespace containing the environment
variables specific to the current user's session.
The documentation you linked states:
When you change environment variables in PowerShell, the change
affects only the current session. This behavior resembles the behavior
of the Set command in the Windows Command Shell and the Setenv command
in UNIX-based environments. To change values in the Machine or User
scopes, you must use the methods of the System.Environment class.
So defining/changing an environment variable like this:
$env:ChocolateyInstall = [Environment]::GetEnvironmentVariable('ChocolateyInstall', 'Machine')
Will change it for the current session, thus being immediately effective, but will also only be valid for the current session.
The methods of [System.Environment] are more fine grained. There you can choose which environment variable scope to address. There are three scopes available:
Machine
User
Process
The Process scope is equivalent to the Environment drive and covers the environment variables available in your current session. The Machine and the User scope address the permanently stored environment variables1. You can get variables from a particular scope like this:
[Environment]::GetEnvironmentVariable('ChocolateyInstall', 'Machine')
And set them with:
[Environment]::SetEnvironmentVariable('ChocolateyInstall', 'any/path/to/somewhere', 'Machine')
If you want to have new variables from the Machine or User scope available in your current PowerShell session, you have to create a new one. But don't open a new PowerShell session from your current PowerShell session, as it will then inherit all environment variables from your current PowerShell session (source):
Environment variables, unlike other types of variables in PowerShell,
are inherited by child processes, such as local background jobs and
the sessions in which module members run. This makes environment
variables well suited to storing values that are needed in both parent
and child processes.
So, to address the problem you described, you most probably changed your permanently stored environment variables1, while already having an open PowerShell session. If so, you just need to open a new (really new, see above) session and you will be able to access your environment variables via the Environment drive. Just to be clear, opening a new session will even reload environment variables of the Machine scope. There is no reboot required.
1 That are the environment variables you see in the GUI when going to the System Control Panel, selecting Advanced System Settings and on the Advanced tab, clicking on Environment Variable. Those variables cover the User and the Machine scope.
Alternatively, you can open this GUI directly by executing:
rundll32 sysdm.cpl,EditEnvironmentVariables
How comes cmd.exe shows different values for PSModulePath than PowerShell does?
PowerShell:
\\share\user\WindowsPowerShell\Modules;
C:\Program Files\WindowsPowerShell\Modules;
C:\Windows\system32\WindowsPowerShell\v1.0\Modules\
CMD:
C:\Windows\system32\WindowsPowerShell\v1.0\Modules\
The environment variables seems to be modified 'localy' at execution ( changes are not saved to the system ).
Running cmd from within the powershell console should work as you expect :
PS>cmd /c echo %psmodulepath%
Anytime you start up PowerShell it will create a set of environment variables for that session. These can all be found under the $env (ex. $env:PSModulePath). There is a set of default values that go here. These default values are hard corded but you can of course modify those default values by changing it in one of the profile script locations.
As for CMD.exe, whenever it starts up it too will create environment variables, however it's environment variables are pulled from the OS environment.
Go to Control Panel -> System -> Advanced Settings -> Advanced Tab -> Environment Variables
My purpose is to deploy user configuration files under:
$HOME/.appname for Unix/Linux.
\Documents and Settings\(user)\Application Data\AppName for Windows.
What are the API's or group of functions that I can use, with the appropriate {$IFDEF}'s, so I can deploy my config files on the appropriate places?
Better use the correct function:
http://www.freepascal.org/docs-html/rtl/sysutils/getappconfigdir.html
result:=getappconfigdir(false)
You'll likely end up using the GetEnvironmentVariable function. Under Unix-like OSs, you will use the HOME environment variable. Under Windows, you'll use the APPDATA environment variable.
I'm having this weird situation :
My user's and system's PATH variable is different than the PATH in powershell.
When I do :
PS C:\$env:path
C:\Windows\System32\WindowsPowerShell\v1.0\;c:\oldpath
However this is not correct, it looks like it stuck on some old PATH variable of my system, so none of the udpates I've done on it didn't change this variable (I do restart after every change to test).
Why is this happening? Do I have to set a PATH variable just for powershell?
The change might be "delayed", so try one or more of these solutions:
Log off and on again;
Task Manager > Restart "Windows Explorer" (explorer.exe)
Restart your launcher app (launchy, SlickRun, etc)
Reboot
Explanation:
Powershell will inherit the environment of the process that launched it (which depends on how you launch it). This is usually the interactive shell (explorer.exe). When you modify the environment from computer properties, you modify the environment of explorer.exe, so if you launch powershell from explorer.exe, (for example from the start menu) you should see the new environment.
However, if you launch it from something else (say a cmd.exe shell that you already had opened), then you won't since that process was launched under the old environment.
In other words: be careful how you are launching things.
In my case, I installed an app that incorrectly added itself to the PATH by creating a powershell profile that would override $env:PATH and blow out the existing configuration every time I started powershell.
Check if you have profile at USER\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1 and if it's doing anything fishy like setting $env:PATH.