From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 92866 invoked by alias); 17 Nov 2016 19:34:30 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 92832 invoked by uid 89); 17 Nov 2016 19:34:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-101.5 required=5.0 tests=AWL,BAYES_00,GOOD_FROM_CORINNA_CYGWIN,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=rice, Rice, Vince, vince X-HELO: drew.franken.de Received: from mail-n.franken.de (HELO drew.franken.de) (193.175.24.27) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 17 Nov 2016 19:34:28 +0000 Received: from aqua.hirmke.de (aquarius.franken.de [193.175.24.89]) (Authenticated sender: aquarius) by mail-n.franken.de (Postfix) with ESMTPSA id 89C7E721E280D for ; Thu, 17 Nov 2016 20:34:24 +0100 (CET) Received: from calimero.vinschen.de (calimero.vinschen.de [192.168.129.6]) by aqua.hirmke.de (Postfix) with ESMTP id CD9715E049E for ; Thu, 17 Nov 2016 20:34:22 +0100 (CET) Received: by calimero.vinschen.de (Postfix, from userid 500) id C1D1AA804AE; Thu, 17 Nov 2016 20:34:22 +0100 (CET) Date: Thu, 17 Nov 2016 20:26:00 -0000 From: Corinna Vinschen To: cygwin@cygwin.com Subject: Re: CYGWIN_NOWINPATH (was Re: /etc/profile: avoid multiple /usr/bin in PATH) Message-ID: <20161117193422.GA31883@calimero.vinschen.de> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <20160908120718.GE3860@calimero.vinschen.de> <5254219C-D6EF-47E7-BE79-3EEDC8DA6604@solidrocksystems.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qDbXVdCdHGoSgWSk" Content-Disposition: inline In-Reply-To: <5254219C-D6EF-47E7-BE79-3EEDC8DA6604@solidrocksystems.com> User-Agent: Mutt/1.7.1 (2016-10-04) X-SW-Source: 2016-11/txt/msg00211.txt.bz2 --qDbXVdCdHGoSgWSk Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 2823 On Nov 17 12:11, Vince Rice wrote: > > On Nov 17, 2016, at 12:04 PM, Francis Litterio wr= ote: > >=20 > > On 9/8/2016 8:07 AM, Corinna Vinschen wrote: > >> On Sep 5 10:36, Doug Henderson wrote: > >=20 > >>> I set CYGWIN_NOWINPATH=3D1 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. > >>=20 > >> 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. > >=20 > > Yes, but Explorer induces confusion as follows (seen on Windows 7): > >=20 > > 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%". Environme= nt variable foobar is not set. > >=20 > > 2. Enter "setx foobar 99" to add foobar to the persistent environment v= ariables in the Registry. > >=20 > > 3. Enter "echo %foobar%" again in the same Command Prompt. Still see "= %foobar%". No change in that process's environment, as expected. > >=20 > > 4. Launch a new Command Prompt from the Start Menu. Enter "echo %fooba= r%". See "99". Clearly, Explorer updated it's environment from the Regist= ry and passed the change to the new child process. > >=20 > > This leads people to think that environment variables stored in the Reg= istry are special, when in fact it's Explorer's doing. >=20 > 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 --=20 Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat --qDbXVdCdHGoSgWSk Content-Type: application/pgp-signature; name="signature.asc" Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYLgY+AAoJEPU2Bp2uRE+gS4IP/2IUR4hB13xi/CKu4kIjgFPe BmfqQg8tiezbLKg5+5PmmUNmY00sGBdyig1HC9lGj5g3bBPRH+sVWxfTN4N0s69q 9Sgnfrex5Ucn7+tKw18eWxBqjavKl7SpfKcFOvuj1RFnP+Gai1UKmad24aYo9Yai JVOrxqXOc5PHfBF3Ne7P08TeU5AkgsFUbU3+yp/T8X2/EUJiZ/PaTGcnN0/sMtEE mFMUkRbd2ZbVw9AUL73eRBlHYg5uehs/hl9PQzSPLjPT6agAiWVf0zNy/qiXnt6c PAGf7SLMwO8RDudEvr6CsLIQRryGClKa8aqkcsnpAKWZLWwiR99O2joXzN46OBBR lEw8D9BoB0bkUCUXmFy058ar/I/pnEd9WcMQcyceNKegMZQ9Ht7kNWogMoyOf8uV THgXm91uQfoyZROG0iIzD5O8wlA11Zuh911WTiEIY5GWakqqgB8OJW07rngaMyh0 /7MtNT4DtGDVIE51k1alkR1K5kS/4C0kP7oB2h0uBVmYA7ExXiwBrT37W68QOSqN pHJwj5Bmx9QwffORbvH+AS8scXWdfq3mlnmhKMbLrI/ZmLnryQgeFVBgiLQCYo2D 75Ags13ER2QsLVHoXDjbq7wpE0hXp56Cmja+pZXmbjxRrLn3lbj/YltXqhpxKzLg wx6cvz4FHUoEEcwGR1Pn =bLmg -----END PGP SIGNATURE----- --qDbXVdCdHGoSgWSk--