View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002156 | Double Commander | Logic | public | 2018-10-22 12:12 | 2018-11-11 01:19 |
| Reporter | msz- | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | new | Resolution | open | ||
| Projection | none | ETA | none | ||
| Product Version | 0.8.4 | ||||
| Summary | 0002156: Refresh environment variables when this is broadcasted by system | ||||
| Description | At least on the Windows there is a WM_SETTINGCHANGE message which is broadcasted when the environment variables (or other system settings) were changed. It is required to (optionally) listening to this message and refresh the environment accordingly, otherwise e.g. the newly opened command prompts (after environment change) still have the old environment. | ||||
| Steps To Reproduce | Run DC. Change/introduce/delete some environment variable on system level. Open a new command prompt from DC. Check that the changed environment variable is up to date. - FAIL, environment changes are not applied at all. | ||||
| Tags | No tags attached. | ||||
| Fixed in Revision | |||||
| Operating system | Windows | ||||
| Widgetset | Win32 | ||||
| Architecture | |||||
| related to | 0001611 | acknowledged | Terminal don't apply new system environment variable |
|
|
Thank you for mentioning WM_SETTINGCHANGE, I always wondered how some programs immediately "knew" system changes, but never looked it up. But could you please describe why this should be done with environment variables? Quote from https://docs.microsoft.com/en-us/windows/desktop/procthread/environment-variables --begin quote-- By default, a child process inherits the environment variables of its parent process. --end quote-- Please correct me if I am misunderstanding here something, but you are requesting changing the default behaviour as outlined by the operating system (AFAIK Windows and Linux behave the same in this regard, I know nothing about macOS). IMHO there should be a good reason before doing that. If you need a changed environment variable in a new command prompt instance, I see 2 options: (1) start the command prompt from outside DC, e.g. use the Win-R combination and type cmd+Enter (2) restart DC before starting a new command prompt |
|
|
Programs like DC are a specific kind of system wide tools. I expecting that it is far more common requirement to automatically update the environment than to use the frozen one. In my case I'm developing an old system where every module and version requires a specific environment. This environment preparation is quite complex and is done using a special application which results also to changed system environment variables. The usual workflow is to switch the environment, navigate to particular module (= directory - therefore use of some file commander is helpful) then open a cmd prompt (or some macros/batches). In case DC is not listening to this notification I have to restart it after every environment switch, otherwise I could use the same instance, just change the directory and execute some prepared batch or the cmd prompt from DC. Btw. TotalCmd is listening to that and updates the variables. Your quota about parent-child is correct for command-line kind of programs, but when you read the doc of https://docs.microsoft.com/en-us/windows/desktop/winmsg/wm-settingchange WM_SETTINGSCHANGE there is written: In general, when you receive this message, you should check and reload any system parameter settings that are used by your application. Just a note: because sometimes the env. variable settings are done in an unstandard way (e.g. setting a path via registry), I'm firing this event manually from own tool. So if you will implement that please consider also this case (some event parameters may be NULL - as described in the doc). |
|
|
Thank you for the explanation. It appears messy to me: --begin quote-- This parameter does not usually indicate which specific system parameter changed. (Note that some applications send this message with lParam set to NULL.) In general, when you receive this message, you should check and reload any system parameter settings that are used by your application. --end quote-- For the environment variables they suggest: --begin quote-- To effect a change in the environment variables for the system or the user, broadcast this message with lParam set to the string "Environment". --end quote-- Honestly I don't understand how then the environment variables are passed on, I see using the registry as the only way to really get that done? SystemParametersInfo lists a lot of system parameters at https://docs.microsoft.com/en-us/windows/desktop/api/winuser/nf-winuser-systemparametersinfoa , but I cannot find environment variables mentioned in there. Under Linux it would be even more difficult, if I understand this here correctly: https://stackoverflow.com/questions/15541321/set-a-parent-shells-variable-from-a-subshell As a workaround can you add in your preparation the 1st step to use taskkill (apparently it sends a WM_CLOSE first) to close DC and in the last step start DC again? (I assume that you are not running any background copying in DC at that time.) Alternatively use pskill (from Windows Sysinternals; if you add the parameter /accepteula it won't ask the first time to accept the EULA). We don't know what the developers think about that request, but this certainly is something highly specific and probably not needed by 99.99% of the users. |
|
|
Would be nice to have, but it's really complicated. I've looked into it some time ago, AFAIR I've found no clear way to get the new env vars without resorting to hacks like reading them from the registry. |
|
|
It is already implemented for PATH environment variable. But it is slightly complicated for other variables because variable can be added/deleted. Also sometimes is not good to do that, for example: user execute DC with changed enviorment. If DC will update enviorment in this case then user changes is lost. |
|
|
>>> user execute DC with changed enviorment. If DC will update enviorment in this case then user changes is lost. Good point. Could be mitigated to some extent if we read system environment on start and either: - remember the difference between starting DC env and system env and reapply it on every system env update, or - get the difference between updated system env and previous system env and apply only the changes to the DC environment. But this way it will overwrite user-defined starting env if one of those variables is defined system-wide and has changed. All of this is very hackish and therefore should be configurable if ever implemented. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2018-10-22 12:12 | msz- | New Issue | |
| 2018-10-23 04:41 | w2017 | Note Added: 0002816 | |
| 2018-10-23 13:25 | msz- | Note Added: 0002824 | |
| 2018-10-23 13:28 | msz- | Note Edited: 0002824 | |
| 2018-10-23 13:29 | msz- | Note Edited: 0002824 | |
| 2018-10-23 19:27 | cordylus | Relationship added | related to 0001611 |
| 2018-11-10 18:32 | w2017 | Note Added: 0002896 | |
| 2018-11-10 22:55 | cordylus | Note Added: 0002906 | |
| 2018-11-10 22:57 | cordylus | Note Edited: 0002906 | |
| 2018-11-10 23:09 | cordylus | Note Edited: 0002906 | |
| 2018-11-10 23:12 | cordylus | Note Edited: 0002906 | |
| 2018-11-11 00:15 | Alexx2000 | Note Added: 0002907 | |
| 2018-11-11 01:19 | cordylus | Note Added: 0002908 |
