Setting path variables


I am having trouble setting the path variables under Windows 10 64 bit.
I would like to change KICAD_SYMBOL_DIR and KISYSMOD to point to C:\Users…
but cannot make them stick. Where are these stored on v5rc?


If you installed KiCad with the option to have system environment variables ticked on at some point (it is default) they will override the menu settings on next start. They can be disabled in Win7 with the following command (Win10 is likely something similar):
Start->(right-click)Computer->Properties->Advanced System Settings->Environment Variables
Then the settings under Preferences - Configure Path in KiCad’s Main window will stick.


Found it. This could be better explained in the documentation. Many users won’t have permission to write to the default locations.
In my opinion being able to edit the value in Preferences, but losing the change on reopening KiCad with no warnings is a bug.
Changing the environment variables to a User path also works.


I think it’s a bug in the installer. I have learned (by the hard way) to always untick it when I install a nightly build. But it’s not clear in the KiCad UI, either. The only place which tells you it’s an evironment variable is the dialog window decoration, and not necessarily all users even know how environment variables work.


Certainly the default should be not set it or it destroys you own custom settings.
The biggest problem is that there is no indication to the user that this has been set. Either prevent editing in preferences or at least pop up a warning that the variable will overwrite the change


Maybe a start-time check and dialog. If the env variable and the value set by the KiCad UI differ, ask the user which one to use. Then the selected value overrides the other, setting it accordingly, so that they will be the same. Would this be a good wishlist item to report?


I will raise this as a bug as the behaviour is unexpected and not explained

Edit Actually it is explained if you view details, could be a lot clearer though


I’m sure is explained in somewhere… If system environment has been defined, then in kicad they result greyed … but it doesn’t seem to be in the manual


I think that it is about time i figured out how to contribute to the documentation.


I agree this is unexpected behaviour for typical Windows applications, but there is precedent in Unix for having environment variables override program settings. In Windows it’s not so easy for users to change env settings, or realise they need to. It’s a dialog you really have to try hard to find.

Last time this was raised with developers the message was “this is intended behaviour and there is no intention to change”. But that was under a different project leader, so you might get a different answer. However, if there was a change, it would need to be backward compatible, I don’t see a clean way to do it.

I was looking for ways to change environment variables in Windows from Python. There is a command “SETX”, which permanently sets user variable (the system setting remains). e.g.

setx KISYS3DMOD C:\ProgramData\KiCad\packages3d

User variables can be permanently deleted with

reg delete "HKCU\Environment" /v KISYS3DMOD /f

but this leaves the system setting. To delete system variables permanently requires a command window started with Administrator

REG delete "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment" /F /V KISYS3DMOD

For Windows users, it’s best to always untick setting of environment variables when installing KiCad. I can see absolutely no benefit to using them, apart from the fact they provide defaults for KiCad when first running. But the KiCad installer does not delete them if they are already there, that is left to the user.


I have commented on this matter in several previous bug reports, as it is a recurrent problem, for intance this one that references two other reports: .

I think a lot would be gained if the Windows installer had the option to install the system environment variables ticked off as default.

Edit: I added another comment in the above mentioned bug report, with link to the discussion here.


Default OFF at least, many Windows users don’t have admin rights and will get 3D model downloading failing due to the Program Files location.