-
-
Notifications
You must be signed in to change notification settings - Fork 574
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature request: Auto update environment variables from system on WM_SETTINGCHANGE like explorer.exe #468
Comments
Explorer ignores, well it actually do not even support, change/apply variables for its process. But when you run ConEmu...
So, I consider processing of this message would be harmful |
Hmm. Probably, ConEmu may ask user what they want to do, when WM_SETTINGCHANGE received. |
I second this feature request. ConEmu does not have to update all variables from the system. But for the PATH variable this functionality is a must. Though because of the env variable export feature mentioned above (granted I understood its mechanism correctly) one will have to think carefully on how to make it right. To keep the internal changes to PATH variable intact you'll have to differentiate changes to the PATH variable introduced by the internal export feature from those introduced by the external changes to system and/or user PATH variables. The idea I have in mind is a bit convoluted, but I'll try to explain it. When ConEmu starts you should save the original PATH variable that was inherited from the parent process to CONEMU_PATH. Here is the pseudo-code for what was described above: // Somewhere when the ConEmu process starts
GetEnvironmentVariable("PATH", &CONEMU_PATH, CONEMU_PATH.Length)
PathChangeDeltas internalPathChangeDeltas = new PathChangeDeltas();
...
switch (Msg.message)
{
...
case WM_SETTINGCHANGE:
CONEMU_PATH = MACHINE_PATH + ";" + USER_PATH;
CONEMU_PATH = ApplyDeltas(CONEMU_PATH, internalPathChangeDeltas);
SetEnvironmentVariable("PATH", CONEMU_PATH);
break;
case WM_INTERNAL_PATH_EXPORT:
String EXPORTED_PATH = Msg.wParam;
newDeltas = getPathChangeDeltas(CONEMU_PATH, EXPORTED_PATH);
CONEMU_PATH = ApplyDeltas(CONEMU_PATH, newDeltas);
internalPathChangeDeltas.Append(newDeltas);
SetEnvironmentVariable("PATH", CONEMU_PATH);
break;
...
} MACHINE_PATH and USER_PATH will have to be pulled from the respective branches of Windows registry. The Append() method, should you choose to actually implement something similar to what I described, can destroy mutually cancelling deltas, e.g. if one delta adds "C:\Windows" to the path and another one removes it then both those deltas can be safely removed. |
@reider-roque #468 (comment) note 1 |
@Maximus5, how does my suggestion of updating only the PATH variable contradict that note? Also, I don't think that you will be able to easily change, if at all, Environment Variables of already started (in ConEmu) terminal processes (not sure what WAP and GitExtensions terminals are, I'm talking about things like cmd.exe, powershell.exe, or sh.exe started inside ConEmu). It is not the right thing to do anyway. But timely update of the PATH variable of the ConEmu process so that all newly started terminals inherit the updated PATH shouldn't be a problem. At least that is the default behaviour I would expect of ConEmu. |
I think explorer.exe update environment variables of itself from the following registry entries on WM_SETTINGCHANGE:
Then explorer.exe start a new process, the new process inherit the new environment variables. |
@strrchr you are correct about registry entries. If you ignore the exported changes from console up to ConEmu process then, well, you will just break that exporting functionality. My suggestion, if implemented, would combine both features. Though I already see that the algorithm I described above is not exactly correct. To calculate correct deltas you'll have to check for differences between PATH that was just exported up from terminal process and the original PATH the terminal process was started with. That is in ConEmu you'll have to store a per terminal process PATH snapshot (taken when that terminal process was started) for the purpose of calculating deltas. On the side note, @Maximus5, consider the following case. You have two different terminals running in ConEmu. Let's say that ConEmu's PATH is "A;B;C". When two terminals were created they inherited that PATH. Now the first terminal makes changes to the PATH variable "A;B;C" -> "K;L;M". And it exports that path up to the ConEmu. Now ConEmu's PATH is "K;L;M". Then the second terminal changes its PATH "A;B;C" -> "X;Y;Z" and exports it up to ConEmu. Boom, you've just overwritten the "proper" PATH that was exported up by the first terminal with "proper" PATH that was exported up by the second terminal. In the above case you allow one terminal to overwrite changes that were made by the other terminal, but at the same time you don't like the idea of overwriting ConEmu's environment by the system-wide environment changes, which, I argue, should at least take precedence to bottom-up environment updates. |
PATH may be set not only by "export". So, PATH actually differs from system at the moment ConEmu starts. However, we may save this startup delta too. |
I use ConEmu as a replacement for cmd, so I want to be able to use my newly added or modified environment variables in new tabs of ConEmu, but it will totally ignore this changes for new tabs for reasons that you mentioned above. Can't ConEmu just have an option for this(auto processing of WM_SETTINGCHANGED) or at least have a menu button or a command that reload all settings? This way new tabs may work with new settings and existing tabs can continue with old copy of variables. |
+1 |
so...there are no way to refresh the environment variables of specific tab other than relogin? |
@zhaoguoyuan Look, even if ConEmu would renew its environment (in roadmap actually) the application, running in ConEmu tab is running on their own responsibility. There is no proper way to "change" environment in some external process. For example, cygwin doesn't ever call Windows environment API functions. |
@Maximus5 I think I understood what you said, I totally agree with that. Obviously there are no perfect on punch solution for all the problems, since "environment variables" is a big topic, especially when ConEmu interact with OS or other software in two ways, maybe we can list up the use cases and try to discuss them separately. |
+1 for this feature. I appreciate that ConEmu can do many wonderful things (export variables, host WAMP and what not) and one day maybe I'll learn to appreciate this too. But for the very simple (and probably the most common) use-case, when ConEmu acts as a multi-tab cmd.exe, it would be nice to minimise the surprise for the user. As said by someone above:
Users come to ConEmu from these less fancy tools and have learned to get around with this not-very-fancy behaviour. Hardly anyone will be able to appreciate the fanciness as something positive... |
The problem is that the behaviour is inconsistent when consoles are set up to open in new tabs.
In one case I inherit the explorer's environment, in the other I do not. Confusing, and bad. If you set up ConEmu to open new windows instead of new tabs, you don't have that problem. Another inconsistency! I don't really care about processing * Although I'm all in favor of #987 -- but at least the current behaviour has a certain logic to it. |
+1 for this feature |
@norswap is correct. Any update on the request? Olivier |
+1 for this feature, at least as a menu option to manually reload environment. Sometimes it's a problem to restart whole ConEmu, e.g. due to long-running process in one of the tabs. Fortunatelly, there's a workaround: Start the new shell (cmd.exe) from explorer and then use ConEmu's function "Attach to..." to move it into ConEmu. |
+1. Very annoying when you have multiple consoles open and have to close all. |
Sort of workaround. |
Call me crazy but its been 3 years, this is basic. Literally I only use Windows because my stupid company is bound to it but I swear never to code again supporting windows in whatever open source projects I contribute... |
Seems like chocolatey has already resolved this issue with a script: I have been using it along with The only "but" I have is that it only works in CMD, so if someone is using cygwin or some other shell derivative then you need to close it, "refresh" CMD and open again. |
The ability to run a script when opening a new tab would indeed be of tremendous help. I don't remember very well (it's been more than 18 months) but I tried to investigate that and I don't think it is possible in ConEmu. The ability to run a script whenever a console is opened (no matter the method) would also help. I someone wants to investigate... |
@norswap
|
Indeed, I thought I had tested that already, but apparently not. I set my init script up to call a script that resets the PATH variable (one could use the |
In my first 5 minutes of using ConEmu, after several years of using several other terminals on Windows, I ran smack into this issue. |
I really can't understand that. Do you change environment variables every 5 minutes on system level? |
My first instinct was to open a new terminal, which didn't work. I then had to kill every terminal before it took effect, which I assumed was a bug. |
@Maximus5 No, but happens frequently that you have some consoles open, you need to install something (changes PATH), then you'd expect that opening a new console tab would have the new path (as it does when you open it from explorer). But nay. So now you either have to launch a new instance of ConEmu (but only if you didn't configure it to be single instance IIRC). Or remember the flag for launching a separate instance (no one does). Or (what people actually do) - clause all open consoles and relaunch. Given how incredibly common that scenario is, and given how many options ConEmu already has, would it really be the end to fetch the new environment variable values from the register when launching a new console? Or potentially add the option to control this behaviour? |
Agree with feature requesters. As many people i also work on different solutions every week and have to install various tools, etc to try them out. Generally i have at least 5-6 consoles open with useful command histories. It really is an incovenience to restart cmder every time i install something because it doesn't have the refreshed PATH. |
When ConEmu receives the |
… PATH). The problem was with `PATH` variable, it contains substitutes `%SystemRoot%`, but they were not expanded during environment refresh.
When I change PATH or some other system environment variables, open a new tab in ConEmu, I think ConEmu should use the new system environment variables.
For explorer.exe, I open a new console by "open prompt here", it does use the new system environment variables.
The text was updated successfully, but these errors were encountered: