Using Version: 5.99.0-unknown-daca9d21f2~131~ubuntu21.04.1, release build It seems to me I can’t use ~/Documents paths pointing to the users home directory when configuring the paths. I have to use an absolute path like /home/{username}/Documents. Can anyone confirm this? Is it a bug or a feature? Should I file a bug report in the gitlab?
Where and how are you using those paths?
In KiCad’s Project Manager / Preferences / Configure Paths I have:
So, if you change for example /home/paul/.local/share/kicad/5.99/3rdparty to ~/.local/share/kicad/5.99/3rdparty does it still find the path? Because it should! Why having an absolute path including the username when having a path relative to the current user is all I need?
In my case I want to use such path in my project paths in the hope it will work on different machines where the project is synced via a versioning repository. The machines have different usernames.
I hope it’s not one of these “It’s not a bug because why do you even want that”-situations.
I understand your wish and agree, but I do not have much interest to dive into it.
- I do not know what the “3rdparty” is for (scripts?
- The “3rdparty” directory is empty, so I would not know how to check what KiCad does with it.
- There are some fixes for KiCad-nightly V5.99 to find symbol and footprint directories. This looks shaky and fragile, and I assume this will get a do-over before V6.0.
- I think GIT has built in mechanisms for path name substitution.
- I don’t think those environment variables are project specific. They also exist if I create a new empty project from scratch.
- The project itself uses ${KIPROJMOD} as it’s home. That should always work.
- I made the KIDATASHEET myself and use it for links to datasheets from my personal libraries, so one environment variable finds them all.
- I’m always having a bit of a *&^%$#@! with little things like path names and directories (folders?) in Linux. Thunar often does not always see files when they change on disk, I’ve had troubles with tildes in the main menu and other small but annoying details. I tend to try to ignore them out of a need for self preservation agains insanity, even though it does not work very well.
Using ${KIPRJMOD} is the recommended way to set up project-relative paths that work on any platform.
Yes, I know about ${KIPROJMOD} but username agnostic home directory paths should work too. Just because users would expect them to work.
Tilde expansion is a shell feature, not part of the file system. Different shells (bash vs csh vs zsh, etc.) handle the tilde similarly but with small differences. Most applications don’t support tilde expansion.
6 Likes
Look carefully at the example Paul gave you. It’s the Configure Paths dialog. It’s meant to be possibly different for each user (or each KiCad setup). You don’t use it in any project. Each project only use ${KICAD6_FOOTPRINT_DIR} etc. It doesn’t give any benefit to use ~ in those path definitions in that dialog because no project has that actual path stored anywhere, and what’s in that dialog is part of the user settings of KiCad. They are stored in kicad_common.json (in v5.99) in the user settings.
So, I repeat what Paul asked and what you didn’t answer:
Small clarification: they are stored here if they are not given by the system environment. Some KiCad packages on certain Linux distributions set these variables via the environment, so if you are using one of these packages, or you set the variables in your environment manually, the settings in the json file are ignored, and these paths cannot be permanently changed through KiCad’s Configure Paths dialog.
1 Like
Tilde expansion started as a shell feature, I remember being excited when it was introduced on Unix, however over the years some programs have adopted the convention. For example, try it in vim via the :r command, it works. There is even a Posix library routine wordexp(3p) to assist programmers. Evidently KiCad isn’t one of those that support ~. Environment variables may be a better solution.
As I’m experimenting a bit with the Nightlies and my “KIDATASHEET” environment variable was a bit old, I decided to make a new one (also because of this thread).
So I made a KICAD_DATASHEET_DIR with a tilde:
And In my brand new schematic symbol:
I added a link to it’s datasheet:
And it works. [Ctrl + d] opens the datasheet in my most usable and least annoying PDF viewer.
I’m running Linux Mint TwentySomething with XFCE and my current nightly is:
Application: KiCad PCB Editor
Version: 5.99.0-unknown-daca9d21f2~131~ubuntu20.04.1, release build
Libraries:
wxWidgets 3.0.4
libcurl/7.68.0 OpenSSL/1.1.1f zlib/1.2.11 brotli/1.0.7 libidn2/2.2.0 libpsl/0.21.0 (+libidn2/2.2.0) libssh/0.9.3/openssl/zlib nghttp2/1.40.0 librtmp/2.3
Platform: Linux 5.4.0-84-generic x86_64, 64 bit, Little endian, wxGTK, xfce, x11
Build Info:
Date: Sep 13 2021 04:12:49
wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+ 3.24
Boost: 1.71.0
OCC: 7.3.0
Curl: 7.68.0
ngspice: 31
Compiler: GCC 9.3.0 with C++ ABI 1013
Build settings:
KICAD_USE_OCC=ON
KICAD_SPICE=ON
Now, if I only knew why I’m stuck on OCC 7.3.0 while most of the rest of the world moved on to OCC 7.5.0…
1 Like
However PCB Editor may be opening the PDF viewer via a shell, e.g. via system(3), so that’s why it works.
I used the Schematic Editor 
And due to some *&^%$#@! in my head I forget most of the things I learn about Linux pretty quickly, so at some time I stopped trying to learn how it works, but it does work for me, and for me it does not matter much whether it runs via a shell , my system or a loophole in the Matrix.
Probably doesn’t work for libraries since that’s an internal KiCad file open. The behaviour of programs that don’t do tilde expansion vexes some people who think it should work, but the author didn’t intend it to.
1 Like
I’ve opened an issue: https://gitlab.com/kicad/code/kicad/-/issues/9213
I think this is an avoidable inconvenience for the user and should be fixed for usability and comfort.
1 Like
As others have said, tilde is a shell feature. NEVER use tilde in scripts or settings files.
Use $HOME instead, this always works.
Interesting! Could you give an example? I was reading somewhere here that nested variables should not be used, so one variable in the value of another variable.
I don’t think you have understood how the path configuration is used. Each user must define them for themselves anyway. You wouldn’t gain anything except not needing to type some more characters when you add the home dir path into that dialog. Anywhere else you should then use the variable which points to that home dir. Again, you would only save some characters (typing only ~ instead of e.g. $USR_HOME) if ~ would be recognized. And what’s more important, if you would use ~ it would always point to the current user’s home dir, whether the user want’s that or not. Relocating e.g. libraries would be impossible (without using file system links).
What about project specific footprint libraries (which is where I discovered this behavior)?
That was already answered. Use ${KIPRJMOD} (not KIPROJMOD even though craftyjon said so). It always points to the current project’s directory. Using ~ would only make it less flexible because it would cement the location of the libraries and all users of that project would need to have the libraries in their home dir. Also relative paths, …/…/ etc. work with KIPRJMOD, so you can create a setup where all the distributed stuff is in identical path structure for all users but the whole can be relocated, and the libraries are common for several projects.
1 Like