public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Michael Haubenwallner <michael.haubenwallner@ssi-schaefer.com>
To: cygwin@cygwin.com
Subject: Re: How to query the value of %SystemDrive% in an empty environment?
Date: Wed, 07 Aug 2019 12:41:00 -0000	[thread overview]
Message-ID: <fa465b72-8a91-fa7a-8a9e-2dd2cc5e1ee0@ssi-schaefer.com> (raw)
In-Reply-To: <20190807111943.GC11632@calimero.vinschen.de>

On 8/7/19 1:19 PM, Corinna Vinschen wrote:
> On Aug  7 13:08, Michael Haubenwallner wrote:
>> On 8/7/19 4:33 AM, Brian Inglis wrote:
>>> On 2019-08-06 09:20, Michael Haubenwallner wrote:
>>>> using 'env -i' to create an empty environment, the SYSTEMROOT and WINDIR
>>>> environment variables are preserved (or recreated):
>>>>  $ /usr/bin/env -i /usr/bin/env
>>>>  SYSTEMROOT=C:\Windows
>>>>  WINDIR=C:\Windows
>>>> And with cygpath, there is the -A, -D, -H, -O, -P, -S, -W and even -F flags
>>>> to query the values for various directories.
>>>> Now what I've failed to find is how to query the value for the "SystemDrive"
>>>> environment variable.
>>>> The problem behind is that I'm using "vswhere.exe" to locate some Visual Studio
>>>> environment from within some scripts run via 'env -i', causing vswhere.exe to
>>>> create a directory named "%SystemDrive%" in the current working directory:
>>>> So I better ensure the SystemDrive environment variable is set for vswhere.exe.
>>>> Any ideas?
>>>
>>> There is a reg entry:
>>>
>>> $ head
>>> /proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Control/SystemBootDevice;
>>> echo
>>> multi(0)disk(0)rdisk(1)partition(3)
>>>
>>> but how do you convert that to a device letter?
>>>
>>> SYSTEMDRIVE is a dynamic env var created at startup pointing to the boot drive
>>> letter. It is not instantiated anywhere else as far I could find. A number of
>>> low level reg entries use that env var. Only option is to pass it through:
>>
>> Heck, even CreateEnvironmentBlock() relies on SYSTEMROOT env var being set,
>> otherwise returning things like ProgramData="%SystemDrive%\ProgramData".
> 
> So, what does this have to do with Cygwin in case you clean out the
> environment?  This is nothing you want to do if you plan to start
> a non-Cygwin executable.

I do prefer to have full control over the environment, recreating the needed
vars from the registry or similar, because I did have too much troubles with
polluted environment already.  This also applies to setting up some wrapper
around the MSVC toolchain, that provide the vswhere.exe helper these days.

Actually I would have been fine it was obvious enough to locate SYSTEMDRIVE,
much like SYSTEMROOT and WINDIR are available via cygpath, or reading other
specific environment variable values from /proc/registry/.

As SYSTEMROOT and WINDIR are preserved already, even if they are available
via cygpath as well, also preserving SYSTEMDRIVE simply feels suitable here.
And even more since I found this commit, which seems to intent the same:
https://cygwin.com/git/gitweb.cgi?p=newlib-cygwin.git;a=commitdiff;h=1f99dd3ecf3252517363ec8f0fec4b0a95706f31

Anyway: If it is possible to map above SystemBootDevice registry value to
SYSTEMDRIVE, I would be fine as well.

Thanks!
/haubi/

--
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

  reply	other threads:[~2019-08-07 12:41 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-06 15:20 Michael Haubenwallner
2019-08-06 15:41 ` Corinna Vinschen
2019-08-06 15:47   ` Bill Stewart
2019-08-06 15:53     ` Corinna Vinschen
2019-08-06 16:10       ` Bill Stewart
2019-08-06 16:25         ` Corinna Vinschen
2019-08-06 17:08           ` Bill Stewart
2019-08-07  2:33 ` Brian Inglis
2019-08-07 11:09   ` Michael Haubenwallner
2019-08-07 11:19     ` Corinna Vinschen
2019-08-07 12:41       ` Michael Haubenwallner [this message]
2019-08-07 14:31         ` Corinna Vinschen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=fa465b72-8a91-fa7a-8a9e-2dd2cc5e1ee0@ssi-schaefer.com \
    --to=michael.haubenwallner@ssi-schaefer.com \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).