Boost logo

Boost-Build :

From: Johan Nilsson (r.johan.nilsson_at_[hidden])
Date: 2005-06-02 01:33:28

"Eric Niebler" <eric_at_[hidden]> wrote in message
> Brian Braatz wrote:
>> It
>>>turns out that if you lauch a cmd.exe shell as another user, then you
>>>don't get these environment variables defined for some reason.
>> [Brian Braatz Writes:]
>> Side Note:
>> Eric, I ran into this while writing security code for Win32. Basically,
>> you may have a "user which has rights to do something" on a given box,
>> but if the user does NOT have a profile then you see the behavior you
>> mention.
>> In my case, the problem was solved by manually logging into the machine
>> with the other user (to make windows create a profile for you), and then
>> doing the "runas". There is also an API for this (sorry not at the tip
>> of my fingers).
>> Basically, the profile is what engages all those files in your
>> "\Documents and Settings\" dir
> That's not it. This user *has* logged in and *does* have a profile. But
> when I'm logged in as user2 and I run cmd.exe as user1, I don't get the
> env vars.
> However, I *do* get the USERPROFILE env var correctly defined, and it
> points to the same place that %HOMEDRIVE%%HOMEPATH% should. Perhaps that
> would be a better fallback?

As for having USERPROFILE as a fallback - I'm not so sure. For me,
%USERPROFILE% AND %HOMEDRIVE%%HOMEPATH% points to separate places.

I usually change the home path after creating a new user by e.g. invoking
Start/Administrative Tools/Computer Management/System Tools/Local Users and
Groups/Users, selecting Properties for the user, switch to the Profile Tab
and then changing the Home Folder/Local Path.

(And yes, I do detest having C:\Documents and Settings\<username> as my home
path ;-)

// Johan


Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at