%PATH% modified by Code::Blocks

[Folco]

Hi,


I have some trouble. I run under Win XP SP3.

- When I use a terminal on the desktop, I get that :
:> echo %PATH%
C:\WINDOWS\system32;C:\WINDOWS;C:WINDOWS\system32\Webm;C:\Program Files\GCC4TI

Note the "C:\Program Files\GCC4TI" which allows me to run a custom compiler I use with Code::Blocks.

- When I use the Tool I created under C::B (it juste calls cmd, the Win32 terminal), I get that :
:> echo %PATH%
C:\Program Files\CodeBlocks\MinGW\bin;C:\WINDOWS\system32;C:\WINDOWS;C:WINDOWS\system32\Webm;C:\Program Files\GCC4TI
Note that when C::B runs cmd.exe, it add a path to some unix tools in the path, but it removes my own tools !

Why ? How can I solve that ? I am used to run a terminal from C::b under Linux, without exiting C::B itself, by pressing a simple key. Under Win, I can't.

Is it a bug ?

[stahta01]

This is NOT a bug; this is works as designed.
Code::Blocks adding its path is correct.
Why do you think CB is removing a path; since what you posted did NOT support that statement?

I am used to run a terminal from C::b under Linux, without exiting C::B itself, by pressing a simple key. Under Win, I can't.

The tool menu lets me run "cmd" under windows 7 32bit.
The single key thing might be keybinder; I do not use keybinder.

Tim S.

[Folco]

This is NOT a bug; this is works as designed.

So C::B is designed to remove some parts of %PATH% defined under ths OS ?!? Oh God, C::B acts like a virus :shock:

Code::Blocks adding its path is correct.

Yes, why not.

Why do you think CB is removing a path; since what you posted did NOT support that statement?

I don't understand. I don't think C::B removes something, I notice that.


(sorry if I don't understand all what you mean, my english is bad)

[stahta01]

If you think it really is a bug; post directions on how to duplicate the bug!

Tim S.

[Folco]

- Under Win XP, change the system (or user) variable %PATH% in the "System Properties -> Advanced -> Environment variables" (I translate from french).
- Add to it a path to a folder of your choice ("c:\Program Files\GCC4TI" in my case)
- launch C::B
- run a terminal (cmd.exe) from the "Tools" menu.
- run the command echo %PATH%

It seems that C::B has removed the entry you added manually.

[MortenMacFly]

It seems that C::B has removed the entry you added manually.

Sorry, but this is impossible. I suspect that this is a general issue: You can verify by instead of running C::B you run a cmd.exe directly. It should be the same there. C::B does not such magic in the backhand.

Some other thoughts:

Under Windows XP if you change the system path a re-start may be required (or at least a log-off and log-on).

Make sure you are running only one instance (a fresh one) of C::B, otherwise the environment of the parent application is used which is not updated automatically if you change it in the settings... as it is with every other Windows application btw..

Make sure you didn't apply a custom path using the envvar plugin of C::B.

[Folco]

otherwise the environment of the parent application is used which is not updated automatically if you change it in the settings

You are right !

The instance of C::B which I used was launched with RocketDock ( http://rocketdock.com/ ), and I had the problem.
When I launch C::B using the Start Menu of Windows, it works fine ! So it seems to be a RocketDock problem (which would save an old environment state at installation ).

Many thanks for your answers and your help.


edit -> I confirm that by desinstalling/reinstalling RocketDock, all works fine now. Many thanks again. =)

[MortenMacFly]

The instance of C::B which I used was launched with RocketDock ( http://rocketdock.com/ ), and I had the problem.

Changes in the environment settings are (by design) never propagated to running applications on Windows. This is a wise thing to do btws. So you'll need either to launch a new fresh application or kill/restart the (parent of a) running application. Sometimes, if services are involved, this won't do it, too. In that case it can be required to restart Windows. To avoid such hassle, the envvar plugin exists in Code::Blocks. This allows you to create and/or change environment variables at runtime, but only within the focus of Code::Blocks and all child applications started by Code::Blocks (like your compiled application).

BTW: It's similar on Linux, so this is not "a Windows thing".

[Folco]

Thanks for your tips.

[oBFusCATed]

Morten:
You're almost write, because the Explorer detects changes to the env
and all started apps from the explorer has the new env.
And there is no need for logout/login, only app restart.

[MortenMacFly]

And there is no need for logout/login, only app restart.

Not always:

Sometimes, if services are involved, this won't do it, too.

I had that once on a server - the app was communicating with a (license) service that got information from an envvar (bad design, I know). But it really required me to restart the server for the changes to take effect. :-(