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
news:429DE354.9030705_at_boost-consulting.com...
> 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 acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk