This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: CYGWIN_NOWINPATH (was Re: /etc/profile: avoid multiple /usr/bin in PATH)


On Nov 17 12:11, Vince Rice wrote:
> > On Nov 17, 2016, at 12:04 PM, Francis Litterio <flitterio@gmail.com> wrote:
> > 
> > On 9/8/2016 8:07 AM, Corinna Vinschen wrote:
> >> On Sep  5 10:36, Doug Henderson wrote:
> > 
> >>> I set CYGWIN_NOWINPATH=1 in my user environment variables, i.e. in
> >>> registry, not in a cmd shell. I expect it needs to be seen when the
> >>> first cygwin1.dll instance starts, so you would need to stop all
> >>> cygwin processes and servers, just like you do when you run the cygwin
> >>> setup, for this to be effective.
> >> 
> >> Ouch, no!  Environment variables are handed down from parent to child
> >> process.  On all systems, be it Windows, Cygwin, Linux or whatever.
> >> There's *no* other magic involved.  It's just a bunch of strings
> >> inherited from the parent process.
> > 
> > Yes, but Explorer induces confusion as follows (seen on Windows 7):
> > 
> > 1. Open a Command Prompt from the Start Menu (so cmd.exe is a child of explorer.exe), and enter "echo %foobar%".  See output "%foobar%". Environment variable foobar is not set.
> > 
> > 2. Enter "setx foobar 99" to add foobar to the persistent environment variables in the Registry.
> > 
> > 3. Enter "echo %foobar%" again in the same Command Prompt.  Still see "%foobar%".  No change in that process's environment, as expected.
> > 
> > 4. Launch a new Command Prompt from the Start Menu.  Enter "echo %foobar%".  See "99".  Clearly, Explorer updated it's environment from the Registry and passed the change to the new child process.
> > 
> > This leads people to think that environment variables stored in the Registry are special, when in fact it's Explorer's doing.
> 
> None of which has anything to do with needing to re-start cygwin,
> which was Corinna's point.  And, for the record, Explorer doesn't
> induce any confusion at all. A new process gets its environment when
> it starts. Pretty simple to understand.

Well, Francis raises a good point.  The question is of course this:

If Explorer is a process as any other process (and it is), then when you
change the system env, how is it that Explorer notices it and
starts child processes with the changed env?

Under normal inheritence rules this *is* puzzeling.

The solution: Windows GUI applications receive a message in the Windows
Message Queue notifing them of the fact that the system env has been
changed.  If the GUI app cares for this, and Explorer does, the app can
then re-read the system env and refresh its own env with the new data.

This explains how processes started from Explorer *after* changing the
system env immediatly see the changes.


HTH,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Attachment: signature.asc
Description: PGP signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]