Re: CYGWIN_NOWINPATH (was Re: /etc/profile: avoid multiple /usr/bin in PATH)
Greetings, Francis Litterio! >>> 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. It's actually OS and setx's doing. setx sends a signal on OS level, that the environment has been updated, and programs subscribed to it (like Explorer) update their environment accordingly. Predictable, this behavior is not limited to Explorer. F.e. Far Manager do that. -- With best regards, Andrey Repin Friday, November 18, 2016 02:36:52 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
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 Litteriowrote: > > > > 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 signature.asc Description: PGP signature
Re: CYGWIN_NOWINPATH (was Re: /etc/profile: avoid multiple /usr/bin in PATH)
> On Nov 17, 2016, at 12:04 PM, Francis Litteriowrote: > > 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. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: CYGWIN_NOWINPATH (was Re: /etc/profile: avoid multiple /usr/bin in PATH)
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. -- Fran -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: CYGWIN_NOWINPATH (was Re: /etc/profile: avoid multiple /usr/bin in PATH)
On Sep 5 10:36, Doug Henderson wrote: > On 5 September 2016 at 10:04, Jim Reisert AD1C wrote: > > On Sun, Sep 4, 2016 at 10:07 PM, Doug Henderson wrote: > > > >> Note that CYGWIN_NOWINPATH is still undocumented, except in the email > >> archives. See, e.g. > >> > >> https://www.google.ca/search?q=CYGWIN_NOWINPATH+site:cygwin.com > >> > >> CYGWIN_USEWINPATH is also undocumented, except in a non-cygwin.com > >> email archive. > > > > CYGWIN_NOWINPATH is not working for me. > > > > CYGWIN_NT-10.0-WOW AD1C 2.6.0(0.304/5/3) 2016-08-31 14:27 i686 Cygwin > > > > d:\>printenv | grep CYG > > CYGWIN=nodosfilewarning > > CYGWIN_NOWINPATH=1 > > > > When I start bash, I still get my full Windows path as part of the > > bash path. Am I missing something? > > > > I have neither a ~/.login or ~/.profile, only a ~/.bashrc > > 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. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
Re: CYGWIN_NOWINPATH (was Re: /etc/profile: avoid multiple /usr/bin in PATH)
Doug Henderson writes: […] > BTW: I think cygwin1.dll stores the original windows path in the > exported ORIGINAL_PATH variable. I am running Windows 7 Home Premium > on an laptop. No, this is purely done in /etc/profile, cygwin1.dll has nothing to do with it. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: CYGWIN_NOWINPATH (was Re: /etc/profile: avoid multiple /usr/bin in PATH)
Jim Reisert AD1C writes: > CYGWIN_NOWINPATH is not working for me. > > CYGWIN_NT-10.0-WOW AD1C 2.6.0(0.304/5/3) 2016-08-31 14:27 i686 Cygwin > > d:\>printenv | grep CYG > CYGWIN=nodosfilewarning > CYGWIN_NOWINPATH=1 > > When I start bash, I still get my full Windows path as part of the > bash path. Am I missing something? Most likely. This setting is used in /etc/profile and it seems you start bash in a way that doesn't source it. Your first shell should really be a login shell. See 'man bash', section invocation. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: CYGWIN_NOWINPATH (was Re: /etc/profile: avoid multiple /usr/bin in PATH)
I now see what's wrong. 'ORIGINAL_PATH' in my shell environment was so long, I missed the very short 'PATH'. So it is working just fine. -- Jim Reisert AD1C,, http://www.ad1c.us -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: CYGWIN_NOWINPATH (was Re: /etc/profile: avoid multiple /usr/bin in PATH)
On 5 September 2016 at 10:04, Jim Reisert AD1C wrote: > On Sun, Sep 4, 2016 at 10:07 PM, Doug Henderson wrote: > >> Note that CYGWIN_NOWINPATH is still undocumented, except in the email >> archives. See, e.g. >> >> https://www.google.ca/search?q=CYGWIN_NOWINPATH+site:cygwin.com >> >> CYGWIN_USEWINPATH is also undocumented, except in a non-cygwin.com >> email archive. > > CYGWIN_NOWINPATH is not working for me. > > CYGWIN_NT-10.0-WOW AD1C 2.6.0(0.304/5/3) 2016-08-31 14:27 i686 Cygwin > > d:\>printenv | grep CYG > CYGWIN=nodosfilewarning > CYGWIN_NOWINPATH=1 > > When I start bash, I still get my full Windows path as part of the > bash path. Am I missing something? > > I have neither a ~/.login or ~/.profile, only a ~/.bashrc 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. It works for me in both my x86_64 and x86 cygwin installs. I start bash from mintty using the desktop shortcut created by setup (or a copy of it), I have CYGWIN=error_start=d:\cygwin64\bin\dumper.exe, I know this is the wrong dumper for my 32bit install, but I do almost all my work in the 64 bit install, that's not a big deal for me. BTW: I think cygwin1.dll stores the original windows path in the exported ORIGINAL_PATH variable. I am running Windows 7 Home Premium on an laptop. $ uname -a CYGWIN_NT-6.1 Rover 2.6.0(0.304/5/3) 2016-08-31 14:32 x86_64 Cygwin HTH Doug -- Doug Henderson, Calgary, Alberta, Canada -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
CYGWIN_NOWINPATH (was Re: /etc/profile: avoid multiple /usr/bin in PATH)
On Sun, Sep 4, 2016 at 10:07 PM, Doug Henderson wrote: > Note that CYGWIN_NOWINPATH is still undocumented, except in the email > archives. See, e.g. > > https://www.google.ca/search?q=CYGWIN_NOWINPATH+site:cygwin.com > > CYGWIN_USEWINPATH is also undocumented, except in a non-cygwin.com > email archive. CYGWIN_NOWINPATH is not working for me. CYGWIN_NT-10.0-WOW AD1C 2.6.0(0.304/5/3) 2016-08-31 14:27 i686 Cygwin d:\>printenv | grep CYG CYGWIN=nodosfilewarning CYGWIN_NOWINPATH=1 When I start bash, I still get my full Windows path as part of the bash path. Am I missing something? I have neither a ~/.login or ~/.profile, only a ~/.bashrc -- Jim Reisert AD1C,, http://www.ad1c.us cygcheck.out Description: Binary data -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple