XYplorer Beta Club

I don't know if this is a bug or on purpose.

I often need to work with environmental variables, changing them and then doing a build. I refer variables to other variables:
ie.
JAVA_HOME=%JAVA_HOME15%
JAVA_HOME14=c:\java\1.4.2_10
JAVA_HOME15=c:\java\1.5.0_06

PATH=%JAVA_HOME%\bin;etc.

Due to how these are interpretted, i can't type:
set JAVA_HOME=%JAVA_HOME14%
as the path has already been evaluated.

Anyway, I've found that if i launch a command prompt from XY, it does not pick up changes I've made to the environmental variables since launch but instead keeps the variables I'd set when XY was first launched.

I was wondering:
a) can the command prompts be changed to always pick up the latest environmental variables; as if it were being launched with cmd and then cd'd to the directory?
b) can all the command prompt shortcuts be the same shortcut settings? I like to have my command prompts fill the screen (so i set a common size setting and tell it to apply to all)... unfortunately when launching from XY each new location resets the size as if it were a new shortcut.

I'm not running the latest beta atm, but i think both of these will still be the case.

spamalam wrote:a) can the command prompts be changed to always pick up the latest environmental variables; as if it were being launched with cmd and then cd'd to the directory?
b) can all the command prompt shortcuts be the same shortcut settings? I like to have my command prompts fill the screen (so i set a common size setting and tell it to apply to all)... unfortunately when launching from XY each new location resets the size as if it were a new shortcut.

a) No. ENV vars are read once at first usage and then cached.
b) I don't understand the question.

admin wrote:b) I don't understand the question.

I think I just figured it out after reading it about 5 times! It seems to refer to the "Open Command Prompt here" function and the DOS window size that is thus created...user wants to have all these windows be a particular size, I suspect.

I think that the user wants the env variable settings for a new command window read from the registry at the time the command window is opened. This way you can use the Computer Properties dialog to change the environment settings and get a new window with those settings. This seems to be the way that Explorer works.

Edit: Umm looks like I should read a little more carefully - I'm talking about a), which Don has already addressed, but still I think that this is the behavior that should probably apply to whenever a program is launched - not just a command window.

@a, well that's a bugger then How does it work in explorer? Using the "command prompt from here" plugin (windows powertool), if i change my varaibles and launch a cmd session through explorer it uses the new variables not the ones from explorer launch. This is the behaviour that would be highly beneficial.

@b), As an example:

I load up a command prompt from c:\fluffy, and then change the properties to make it fullscreen and change the colour to green (or something), then load up a command prompt from c:\fluffy\pillow all of my changes for the cmd.exe that's just been launched are back to default.

I'm guessing its because the title of the cmd window has changed?

I guess its not a big deal if a can not be addressed, since it largely invalidates the usage of "command prompt from here" for me if i can't have it pick up the latest varibles

oh well

IMO, for cmd line monkeys these are two very good suggestions. I've known a couple of Java devs who do this kind of thing the whole time (for testing between JRE versions).

Does it really take all that long to read the ENVs before a cmd line is opened up each time? It seems a bit silly for a cmd line in a power-user tool to be out of date with the rest of the system seeing as how a cmd line is only going to be used by power users.

lukescammell wrote:IMO, for cmd line monkeys these are two very good suggestions. I've known a couple of Java devs who do this kind of thing the whole time (for testing between JRE versions).

Does it really take all that long to read the ENVs before a cmd line is opened up each time? It seems a bit silly for a cmd line in a power-user tool to be out of date with the rest of the system seeing as how a cmd line is only going to be used by power users.

It takes not that long but long enough to warrant caching.

What I could do is:
(a) a menu command to explicitly Refresh ENVs Cache
(b) a tweak to always refresh it before using an ENV
(c) well, if it's just before a cmd line is opened... I could do that! Any objections anybody?

One of the options would be nice.

Of course i could create bat files that switch the env environments and stick them all over the place, which I have done in the past, however this would disrupt / negate the right click and command prompt from here within XY and also be very annoying to maintain when ctrl+break is much easier for updating ENV settings. They are also referential, so JAVA_HOME can be set to JAVA_HOME15 which is placed on the path. Some way for XY to refresh those env values and pass them onto the cmd would be very welcomed.

Any options for feature b?

spamalam wrote:One of the options would be nice.

Of course i could create bat files that switch the env environments and stick them all over the place, which I have done in the past, however this would disrupt / negate the right click and command prompt from here within XY and also be very annoying to maintain when ctrl+break is much easier for updating ENV settings. They are also referential, so JAVA_HOME can be set to JAVA_HOME15 which is placed on the path. Some way for XY to refresh those env values and pass them onto the cmd would be very welcomed.

Any options for feature b?

But b) would slow down all operations using ENV variables (scripting, UDCs...) a bit. Any other opinions out there? The tweak would be DoNotCacheEnv = 1 or so...

What about a big button with refresh ENV variables? Would at least avoid having to restart XY to refresh and won't hit scripting.

spamalam wrote:What about a big button with refresh ENV variables? Would at least avoid having to restart XY to refresh and won't hit scripting.

Menu View | Caches | Refresh ENV Cache would be the natural place...

admin wrote:

spamalam wrote:What about a big button with refresh ENV variables? Would at least avoid having to restart XY to refresh and won't hit scripting.

Menu View | Caches | Refresh ENV Cache would be the natural place...

That would be cool

admin wrote:

spamalam wrote:What about a big button with refresh ENV variables? Would at least avoid having to restart XY to refresh and won't hit scripting.

Menu View | Caches | Refresh ENV Cache would be the natural place...

I think there's a Windows message that gets sent when the env changes. You could trap that and update the environment cache automatically.

(Checks SDK) Yes, WM_SETTINGCHANGE.

To programmatically add or modify system environment variables, add them to the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Environment registry key, then broadcast a WM_SETTINGCHANGE message. This allows applications, such as the shell, to pick up your updates.

Paul.

pmoore wrote:

admin wrote:

spamalam wrote:What about a big button with refresh ENV variables? Would at least avoid having to restart XY to refresh and won't hit scripting.

Menu View | Caches | Refresh ENV Cache would be the natural place...

I think there's a Windows message that gets sent when the env changes. You could trap that and update the environment cache automatically.

(Checks SDK) Yes, WM_SETTINGCHANGE.

To programmatically add or modify system environment variables, add them to the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Environment registry key, then broadcast a WM_SETTINGCHANGE message. This allows applications, such as the shell, to pick up your updates.

Paul.

Ah, thanks. Make a note...

Great find pmoore!