#182 launching new cmd doesnt carry old path

[Anonymous]

Reported by: austinflorida@hotmail.com

This is going to need a unique and elegant solution. Admins across the world will be grateful.

Suppose the following scenario:
----------------
You update your Windows system "path" variable using control panel.

You go to start>run>cmd

You type "echo %path%" and you see the *new* path variable, rather than the old one.
----------------

Now, the same process in Launchy:
----------------
You update your Windows system "path" variable using control panel.

You press "alt+space" to run the Launchy window.

You type "cmd" (no quotes) into Launchy.

You type "echo %path%" and you see the *OLD* path variable, rather than the new one.
-----------------

This gave me an hour of frustration trying to figure out why my new command windows weren't taking on the new environment variables as they should. This problem applies to all environment variables, not just "cmd".

For a truly universal "start>run" replacement, Launchy MUST SUPPORT this functionality.

--- Temporary Remedy ---

The current (poor) remedy is to restart Launchy itself every time an environment variable is changed when you want the changes to be reflected upon launching new instances of "cmd" from Launchy.

--- Why does this happen? ---

This happens because new/updated environment variables such as path only appear for newly started processes, and child processes inherit the environment variables of their parent process. For instance, if you run "cmd" within "cmd", with an environment variable change in between, the new prompt /will not/ hold the new environment variables, because the second "cmd" is a child of the first prompt (parent prompt), and the first prompt was started when the old environment variables existed. However, if you start a fresh cmd instance with "start>run>cmd", it /will/ contain the new environment variables because its parent is the OS, which has the new environment variables.

In the same way, "Launchy" acts as the parent, and cmd as its child process, so all new cmd's launched with Launcy start with the environment variables Launchy started with when it started (for most users, when the computer first loads).

--- Resolution ---

? Need a way to hand off the new environment variables whenever "cmd" is called (and perhaps this affects other programs). Maybe there is a way to cause the shell to start "cmd" through the OS rather than through Launchy (so that the resulting child process doesn't inherit launchy's old settings).

Perhaps the scheduling service could be used to start CMDs, with a scheduling time a few milliseconds ahead of the current time or something.

Can anyone think of something more elegant? I already tried a batch file solution which didn't work.

[Nobody/Anonymous]

Logged In: NO

If it can give more weight to this bug reporting, this behavior made me mad too. I so routinely use Launchy now that I had hard time to figure out Launchy was the culprit brick when I observed too changing my envt was not taken into account.

This starts with CMD command, but it stands for any launched command. The idea is: Launchy should start a given command with environment settings as they are _at the time we launching this new command_, not as they were at the time Launchy process itself was started.

[Nobody/Anonymous]

Logged In: NO

I suspect that the System control panel uses some special mechanism of Windows Explorer to signal it to reload the path from somewhere (or maybe even to pass the new path to it).