Every time my computer starts it adds the VS Code paths to the user environment path. I have another program that uses Java and apparently has a known bug that prohibits it from seeing the system path when there is a user path.
Is there any way to disable adding to the user path at system startup?
Related
One can specify the extension dir by running from command line:
code --extensions-dir c:\path\to\ext
However, I would like to set this parameter even when running from the windows menu.
I tried to modify the argv.json file located in the .vscode folder (like for https://code.visualstudio.com/docs/getstarted/locales).
It didn't work.
Does anybody know how to fix this?
Bests
Try creating an environment variable called VSCODE_EXTENSIONS with the value of c:\path\to\ext
As a complement to DG's response
If the VSCODE_EXTENSIONS environment variable is created as a system variable, it seems to affect all users.
In my case, I performed the following steps:
close VSCode on all users (I usually have one session open as
administrator and another as non-administrator)
set the variable VSCODE_EXTENSIONS = c:\ProgramData\Code\extensions\
moved all extensions from the extensions folder of the administrator to c:\ProgramData\Code\extensions\
restart the computer
log in with both users and the extensions were available
It is convenient to mention since then the extensions installed by administrator are available to all users and are installed in the folder mentioned previously.
I am trying to edit my MATLAB path. I have permission, it does not give me an error when I try to edit via the GUI, but when I close and reopen matlab, the changes are gone.
I have edited ~/matlab/startup.m to include the paths I need the most, and this works, but why can't I edit the path via the GUI?
I assume it is saving my path (because there is no permission warning/error), but it may be that something is destroying those changes, or reverting upon each startup, I guess I'm just not entirely sure where to look.
EDIT: I should mention that I did not set this machine up, and it's a UNIX box that may have other configuration scripts that are messing with the path. (I checked bashrc but there's nothing there that would interfere)
Found a script that the previous admin put into the machine's global profile that automatically sets the path to include various toolboxes.
Is there a good technical or other reason why the MS hard-coded the Documents folder as the default location for WindowsPowerShell? MS has been criticized for too much configuration over convention in the past (WCF?), but a case can be made for more configuration in PowerShell. I, and I presume most developers, like to keep their development work centralized in a separate folder or volume away from personal and system files.
For instance, if you install PoshGit, it will install itself in C:\Users\Your Name\WindowsPowerShell\Modules. I don't want it to install itself there but in my own development partition d:\Dev\PowerShellScripts. There's no environment variable that controls this location.
Is there a reason for this or I just don't get it?
Can you explain yourself a bit more.
According to my understanding PowerShell.exe interpreter base directory is the one defined by $env:HOMEDRIVE, $env:HOMEPATH, that can be change using the user profile.
As shown in the screen shots here under :
Edited :
Ok, the screenshot comes from the user property in Active Directory MMC, you've got a simplest one in your windows seven user properties. But this has nothing to do with your problem.
Your problem is around the module installation. The think that you have to know is that Modules can be installed quite everywhere (even on a shared directory with some tricks). By default the environnement variable $env:PSModulePath points to the paths where Get-Module -ListAvailable look for them. So you can add d:\Dev\PowerShellScripts\Modules in this path and then copy the subfolder of C:\Users\Your Name\WindowsPowerShell\Modules created by PoshGit inside your Modules directory and it should work. Modules as opposite to Snapins don't need to be registered.
Now the reason why PoshGit choose to put module in user profile, raser than let you choose the place is PoshGit installer problem.
For more explanations read about Modules and about_environment_variables.
I try to install/run emacs on a Win7 64-bit machine after using it for years on a WinXP 32-bit machine and run into a problem I do not find any help for in the documentation or on the web.
Symptom:
when starting runemacs.exe for the first time it creates the file
*C:\Users\USER\My Documents.emacs.d*
as one would expect (for my administrator as well as for my user account)
and comes up operational
from the second start of runemacs.exe it breaks in the startup phase,
displaying the scratch buffer, ringing the warning bell and displaying in
bottom line the error:
File exists: c:/Users/USER/My Documents/.emacs.d/
buffer messages specifies:
make-directory: File exists: c:/Users/USER/My Documents/.emacs.d/
if runemacs was called with a file to open, i.e. because the file type was
associated with it and the file was opened to edit, the file is not open
and ready to be edited, but a file can be opened via the menu File->Open File...
but my configurations in the file
C:\Users\USER\My Documents.emacs
are not loaded
My goal:
I want to regain the way I used emacs on the old WinXP 32-bit system:
click a file associated with emacs, get it opened and ready for editing, get my configurations in .emacs loaded automatically, i.e. work with emacs seamlessly.
Checks done and failed attempts to fix this:
I tried the following newly downloded versions of emacs
emacs-23.4-bin-i386.zip
emacs-23.2-bin-i386.zip (the one I used on the WinXP)
I had the emacs directory containing the directory stucture (bin, etc, ...)
located at:
C:\Program Files (x86)\emacs-23.4\ (my preferred location)
C:\Emacs\emacs-23.4\
in the download directory, where I originally extracted it
My HOME variable points to:
C:\Users\USER\My Documents (default)
C:\Users\USER\My Documents\ (tried)
My PATH variable contains:
C:\Program Files (x86)\emacs-23.4\bin (default)
or the corresponding other locations which I tried
The ownership and permissions of my C:\Users\USER\My Documents.emacs.d
look OK:
owner is the USER (administrator or standard_user)
permissions grant Full Control
Having originally installed emacs to *C:\Program Files (x86)\emacs-23.4*
using the administrator account, I also tried to use user account installation
instead (to check for some non- obvious parameter/access permission not set
right if the admin account is uses for setup)
For the runemacs.exe executable I manually set the compatibility settings to
Windows XP (Service Pack 3)
default setting after unpacking: no compatibility setting enabled
I removed the private configuration file C:\Users\USER\My Documents.emacs
(inherited from my XP installation) to check whether it produces a screw-up
All that did not change a bit of the described symptom, i.e. either I screwed up
in testing the above and missed a particular setting which should work, or I am looking into the wrong direction...
It is still unclear to me whether this has anything to do with:
W7 64-bit vs. XP 32-bit
environmental parameter screw-up
emacs configuration (.emacs, .emacs.d) screw-up
general stupidity (of me ;-)
... and why is it has emacs a problem with it in the first place, that the .emacs.d directory already exists... That should be the standard case...
Any help and wisdom much appreciated.
First of all, nice question. The details and listing of what you've already tried is helpful.
Some points:
Don't have spaces in key paths (Emacs, and %HOME%). Generally, things work
fine. But when things break it's often hard to debug and trace back to the
fact that some package author didn't take spaces properly into account.
Set a HOME environment variable to your %USER_PROFILE%. Make it
%USER_PROFILE%/home if you must, but I use the former.
Start by running emacs without any customization.
runemacs -Q
When that works, add your customizations one at a time.
n.b. This answer is not relevant to the original question (which was about Windows), but may be useful to Unix users searching for this error message
You will get this error also if emacs does not have the correct permissions on the .emacs.d directory.
Check it
ls -ld $HOME/.emacs.d
And make sure the user you are running under has rwx permissions!
I got similar problems when I installed the new version of emacs on a new installation of the ubuntu 12.10. I get the problem fixed by chmod 777 .emacs.d, that is, as the previous post pointed out, the emacs does not have the access right to .emacs.d directory. Hope this help.
I have build an executable that has the same body (the name is tree.exe) with one that windows is provided at C:\WINDOWS\system32 (tree.com).
I have set my Environment Variables that the path where my .exe resides and normally it eould be executed run, though as the same name appears in a different location the tree.com is run instead.
The question is, is it possible to set the priorities where my tree.exe can be executed instead of tree.com. Furthermore, as after the build the tree.exe is dumped to a server other users have the same problem, they cannot just run directly, they need to locate the actual item and double click it.
Any ideas?
Thanks.
I'm not quite sure, but i think you should have the path to your executable before the system paths in PATH variable. Don't forget to reopen the console after the variables have been changed.