This is the mail archive of the
mailing list for the Cygwin project.
Re: How to query the value of %SystemDrive% in an empty environment?
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
>>>> 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
>>> 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:
Anyway: If it is possible to map above SystemBootDevice registry value to
SYSTEMDRIVE, I would be fine as well.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple