Hi,
I realized recently that mi project can’t represent 3d models set with an environment variable.
Maybe i don’t write correctly mi path : ${KIPRJMOD}/Socket.3dshapes/Socket_header.wrl
But this path worked in the past.
I work on linux mint and mi version of kicad is : 4.0.7-e2-6376~58~ubuntu16.04.1
Do you have an issue ?
It sounds like you have a broken definition.
ENVIRONMENT variables and functions and stuff…
They only make sense with proper care.
Open a terminal or your used shell …
The definition you posted is BASH (ash /zsh and some others ) aware
execute a simple:
echo ${KIPRJMOD}
and make sure this variable is being “exported” to the process you want
IF NOT try:
export $KIPRJMOD
after defined and load you applet/application in the proper process you have exported this variable.
You see. It makes sense only in the proper environments.
Paul
i’m stupid it’s work with KIPRJMOD i just forgot to active the 3d model view 
I try with a personal variable and it’s work.
I will try tomorrow on my other pc but thank “PKTS”.
Please FIX the tip by the correct one here
export KIPRJMOD=/the_full_path/for_your_system
the previous is INCORRECT
the copy and paste preserved the “$” which is not correct
below is ok
export KIPRJMOD
should work on almost all recent ash bash zsh ksh alikes and clones
sorry for the inconvenience of the typo
Paul
Do not manually export KIPRJMOD it is used by kicad internally to point to the current project directory!
If you want personal path variables do not use export either. Set them up in the “kicad main window -> preferences -> configure paths” dialog.
&{KIPRJMOD} work well without exporting variable.
But on mi other desktop i have a strange behavior with a personal variable.
I don’t understand what kicad don’t like. I need to make more test for more informations.
The “PROBLEM” is that KiCAD is also meant to run on MSWin.
And that platform aims to wipe out all good standards
to promote their own patented API.
$HOST, $HOME, $USER, $PATH, $HOSTNAME, $PROXY
are some of the few managed variables by system wide processes
By defining: (for example)
export app_root_vers=4.x
.. $app_root_vers/lib/
.. $app_root_vers/share/
You may very well set multiple concurrent applet versions
running without problems
Trivial and very widely used setup.
Requires a standard good well known shell of course
and the applet must be properly written w/standards in mind
Paul
I really do not understand why you try to force the use of operating system environment variables for this configuration. KiCad has its internal way of setting them. (config file, editable from the KiCad main window -> preferences -> configure paths) This includes in KiCad 5 a nice file browser like interface.
It is much less error prone and much easier to understand by people who do not normally deal with this sort of stuff. I can not think of any downside of using KiCad internals for configuring the path setup.
As the operating system environment variables trump the kicad internals it makes configuration much less intuitive. Especially for people who do not deal with this every few weeks. They will later try to set it in kicad and wonder why it does not work.
The only os side environment variable that makes sense is the one seting kicads configuration directory. (only if you want to run v4 and v5 in parallel or if you want to switch between different configs.)
Even in that case the path variables are set inside the kicad config file.
You see… There has to be a choice:
Or a developer do the things properly and by by properly it means taking into account all relevant best practices and good standards.
Or a developer address some specific goal - being a novice user, or a complete lack of proper understanding or a utmost desire to simplify what is already a standard best practice.
MS did that as a front end for their proprietary APIs as LICENSED software.
A proper “USER” will eventually know how to use the
good well known best practices and how to take advantage of them
As long as the developer has written a good software
which takes advantage of the best practices.
ENVIRONMENT VARIABLES are good best practices.
No need to change that or question that.
You see it should come from the shell in which the parent process
is meant to run. Not the other way around come from inside the applet.
Paul
a postscript … thinking
You see it should come from the shell in which the parent process
is meant to run. Not the other way around come from inside the applet.
I even think that having that inside the GUI is not OK.
it should really be set on the parent shell process.
Not inside the GUI - any GUI.
If you like…
But before doing that use 2 minutes to apply my humble opinion
and comments to something that is around since late 70 or 80s
That is pretty much where the relation of shell and ENVIRONMENT
apply in security standards.
It seems proper to have the shell initialized so just in case
we need to grant high level of privilege (to 3D GPU for example)
with the proper good standards.
Ignore if you don’t concern at all with that security level
Paul
Or if you simply don’t want to waste your time with such irrelevant and incoherent ramblings or anti-MS rhetoric.
I see your point … MS fan boy.
I have nothing against that.
But it is not possible to address these problems without considering
what you call rant.
There is no rant - the points are clear.
You have not even a chroot jail mechanism or even the
chroot calls on that OS.
BUT YOU DO HAVE ON ALL OTHERs.
Including the xchroot on some - and that consideration matters
Running high level 3D GPU intense apps requires some care
That is where the variables come handy - process separation.
No rant.
They (MS) just dont have the necessary environment there
I think we have officially gone of the track. Closed till other mods decide differently. I’m not married to this decision but the tone must change. Feel free to PM me if you strongly believe I closed this in error.
My friend if you think this is not related …
I am wasting my time .
and may be I am in the wrong forum
You are certainly wasting our time. Yes, you are in the wrong forum. If you want to discuss the merits of OS design, please do so somewhere else.