Re: Environment Variable Load Order

Pegasus,

You misunderstand me: this is not MY installer, I am not building it or have
any chance of changing it save by e-mailing the developers and telling them
it is broken. But to do this I need to be able to point them to some
documentation that explains why it is broken. In the end I am going to have
to manually change the paths myself so that it works for the 31 machines I
need to install the software in.

Thanks anyway.

Anyone else has any information on the question I asked?

F. David del Campo Hill

"Pegasus (MVP)" wrote:


"F. David del Campo Hill" <FDaviddelCampoHill@xxxxxxxxxxxxxxxxxxxxxxxxx>
wrote in message news:D978AE86-EDFC-4471-B543-AD3BB03C32B5@xxxxxxxxxxxxxxxx
Dear All,

Does anyone know the order in which (system) environment variables are
loaded upon user log in?

I have an installation program which sets one system environment variable:

GTK_BASEPATH=C:\GTK

and changes the path system environment variable adding:

PATH=%GTK_BASEPATH%\bin;...

This works as expected just after the installation (PATH is effectively
C:\GTK\bin;...), but if you log out and log in again (as any user) you
find
that %GTK_BASEPATH%\bin has NOT been "resolved" and files in that folder
are
not part of the PATH. If you reload the environment variables manually
(right-click My Computer > Properties > Advanced > Environment Variables >
...; no need to actually make any changes, just press OK), then the PATH
includes C:\GTK\bin again (%GTK_BASEPATH% is being "resolved" to its value
when calling PATH).

My assumption is that environment variables are loaded in a certain order
when a user logs in, and PATH is being loaded before GTK_BASEPATH, so it
is
ignoring the %GTK_BASEPATH%\bin at its beginning. But it is only an
assumption, so can anyone provide information on the order or priority of
environment variables?

Thank you for your help.

F. David del Campo Hill

I suspect that there is no published rule that says in which order
such variables are resolved. To make your installation robust, you
should hard-code this variable into the %path%. This is, in fact,
what the installation program should have don. After all, the value
of this variable was fully known to the installation program, hence
there is no justification to soft-code it into the %path%!

While you're at it you might as well tack it to the ***end*** of
the path. The most often used folders (c:\windows\system32 and
c:\windows) should be located at the beginning of the %path%,
for obvious reasons.



.

Relevant Pages

  • libwrap not found (building netatalk on Solaris 9)
    ... version used by Solaris 9. ... I could install the standard tcpwrappers from ... The "influential environment variables" ... an installation prefix other than `/usr/local' using `--prefix', ...
    (SunManagers)
  • Re: Environment Variable Load Order
    ... to manually change the paths myself so that it works for the 31 machines I ... Does anyone know the order in which environment variables are ... loaded upon user log in? ... This works as expected just after the installation (PATH is effectively ...
    (microsoft.public.windowsxp.general)
  • Re: How to get GIF support with Perl-GD library? (Cant locate object method "newFromGif")
    ... Fine tuning of the installation directories: ... Some influential environment variables: ... CXXFLAGS C++ compiler flags ...
    (comp.lang.perl.modules)
  • Re: How to create "user environment variables" programatically for a non-logged on user
    ... > installation program embeds a 3rd party software which I install in ... Now this 3rd party software installs 2 services. ... environment variables on Win32). ... starts and in a short period of time some process connects to SCM. ...
    (microsoft.public.win32.programmer.networks)
  • Re: Environment Variable Load Order
    ... Does anyone know the order in which environment variables are ... loaded upon user log in? ... I have an installation program which sets one system environment variable: ... that %GTK_BASEPATH%\bin has NOT been "resolved" and files in that folder ...
    (microsoft.public.windowsxp.general)