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
why would you want your project-specific libraries relative to your home directory (~ if that worked) and not relative to the project ($KIPRJMOD)?
1 Like
BTW, I have never understood why the name of that variable is KIPRJMOD. Maybe it has started with footprints (which were called modules in prehistoric aeons). It’s also difficult to remember and write. PROJECT_DIR would be better.
2 Likes
Yes, it was originally intended to be a variable to refer to project footprint libraries, and footprints were called modules. You could open a feature request to add a more logically-named alias variable that would do the same thing.
I understand your point very well, but even so: take this as a usability issue, most likely I won’t be the last user trying to use a ~ path and it works for some paths, but not for others, which makes pinpointing the problem harder. The issue could be solved by translating them to absolute paths when entered, but then again, why not just allow ~ paths work everywhere?
I find it a bit disturbing that there is so much energy spend in convincing me that I actually don’t want that (which may be true but not the point). Rather I would like to see the community reaction, like: Wow, that’s a weird thing to ask for but if it saves anyone from a little bit frustration lets just add this to the list of possible improvements and see if someone is willing to take it on. The whole environment variables thing is anyway super complex and in parts broken and convoluted and in the nightly version it’s in a constant flux. So one less thing to be able to do wrong is IMHO a good thing.
We generally try not to add OS-specific features to core functions like path resolving. The tilde-expansion feature of *nix shells isn’t something that works on the filesystem, so we’d have to implement our own mechanism to do it. This would be just one more place for bugs to appear and we’d have to test that our custom tilde expansion system did the same thing as the shell in all cases.
Other users have already described why referencing your project paths to your home directory may not be a good idea. I get why it is frustrating to hear people suggesting that the solution you are trying for may not be the best solution, but I also don’t blame people for trying to suggest things that may end up working better for you in the end.
That said, if you think that putting paths relative to your home directory rather than relative to the project root is best for you, I suggest using the $HOME variable.
2 Likes
I’m not opposed to having ~ support, though I would want it to immediately be replaced by the absolute path. That said it’s quite low on my personal list of priorities – there are many other kicad features that I would personally rather see implemented (given limited developer time).
I do think it’s not the right solution to your problem as described, and I think it’s a strong community that tries to solve each other’s problems in the best way possible.
The whole environment variables thing is anyway super complex and in parts broken and convoluted and in the nightly version it’s in a constant flux. So one less thing to be able to do wrong is IMHO a good thing.
I don’t think this is true? I’m not aware of any parts that are broken, but please report them if they are, otherwise they won’t get fixed. I’m also not aware of constant flux. There were new v6-specific environment variables added at one point, but that’s hardly constant flux.
So one less thing to be able to do wrong is IMHO a good thing.
I see this as an argument against home-directory-relative paths…
Valid question, but totally wrong forum.
You should ask this of the UNIX/POSIX/Linux community. Convince them that every program out there should accept ‘tilde’ as a path element (Good Luck with that).
It has nothing to do with KiCAD. And demanding ‘tilde’ for KiCAD file paths is just asking for trouble concerning portability and functionality. It’s a Shell shortcut for US users. (Most other keyboard layouts don’t even have ‘tilde’ as a separate key).
Different shells implement tilde expansion differently. Even different versions of the same shell often expand the tilde differently.
Which behavior would you want implemented?
Actually, KiCad has built-in tilde expansion functionality: https://gitlab.com/kicad/code/kicad/-/blob/master/common/common.cpp#L270-273.
This was probably added by mistake. I’ve submitted a patch to remove it.
Personally, I like having tilde expansion available. But I’m not advocating for it, because I don’t know if it’s a good idea to add it.
2 Likes
I use tilde often at the command line. I know it works at the open command in kate. I do think doing so would make it easier to use the program, kicad in this case. (this from a guy who only uses linux.)
1 Like
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.