"run as administrator" changes default directory

Discussion in 'Windows Vista General Discussion' started by Matt Hickman, Jul 24, 2007.

  1. Matt Hickman

    Matt Hickman Guest

    I have a batch script, setup.cmd, which depends on the default
    directory, when it runs, being the directory where the script is
    located. So if setup.cmd is located in c:\temp, that batch file
    should run with c:\temp as its default directory.

    Under Vista, setup.cmd needs to be run using the "run as
    administrator" option. However, when I run it this way, the default
    directory is \windows\system32.

    what is the work-around for this bug?

    Thanks

    --
    Mat Hickman
     
    Matt Hickman, Jul 24, 2007
    #1
    1. Advertisements

  2. "Matt Hickman" <> wrote ...
    >I have a batch script, setup.cmd, which depends on the default
    > directory, when it runs, being the directory where the script is
    > located. So if setup.cmd is located in c:\temp, that batch file
    > should run with c:\temp as its default directory.
    > Under Vista, setup.cmd needs to be run using the "run as
    > administrator" option. However, when I run it this way, the default
    > directory is \windows\system32.
    > what is the work-around for this bug?


    Hi Matt,

    This isn't really a bug in Vista, as such; although it's probably a pretty
    surprising "feature".

    When you run the Batch file "as Administrator", you are running it in a
    different user context than the interactive user. Details of the environment
    like "current directory" are tied to the user context. When you run the
    batch file "as administrator" it takes the environment settings of the
    administrator, not of the logged in user. The administrator doesn't know (or
    care) what the current directory of user "MattH" is, it just goes ahead and
    runs the batch file with its own environment.

    In programming terms - in the past, your coding effort has been made easier
    by certain convenient assumptions, which however were not guarranteed to
    always be there (ie current directory will be the location of the batch
    file). So like any good programmer, you need to supply explicit values in
    place of implicit assumptions, as "defensive programming".

    Getting more practical ... the location of the batch file itself is stored
    on the %0 parameter of the batch file's runtime environment. In Windows
    2000, XP, 2003 and Vista, the so-called "Command Extensions" are enabled by
    default. These give batch files many facilities which weren't available
    under MS-DOS. Once of these is substitution performed by the FOR command.
    Type "for /?" at a command prompt, for the full description of the syntax.

    By running FOR over the %0 variable, you can extract the name of the
    directory the batch file lives in, from %0; no matter what the current
    directory is. Here's an example:

    REM =========== top ===========
    @ECHO OFF
    ECHO The current directory is %CD%
    PAUSE
    ECHO The running batch file is %0
    PAUSE
    FOR /F %%I IN ("%0") DO SET BATDIR=%%~dpI
    ECHO The batch file is located in directory %BATDIR%
    ECHO.
    CD /D %BATDIR%
    CD
    PAUSE
    SET BATDIR=
    :END
    REM ========= bottom ===========

    As described in the "FOR /?" help text:

    The modifiers can be combined to get compound results:
    %~dpI - expands %I to a drive letter and path only

    So - the line "FOR /F %%I IN ("%0") DO SET BATDIR=%%~DPI" is setting a new
    variable %BATDIR%, to a value which is the drive letter and path only, of
    %0, the location of the batch file. Then we explicitly CD to %BATDIR%, and
    the current directory will be the directory the batch file is located in.
    It's easy!

    There's a small curiosity about %0. If you echo %0 to the console, it will
    display as the command used to launch the batch file. So if you supply the
    full pathname on the command line, echo %0 will show the full pathname. If
    the directory was on your PATH and you launched the file with just the file
    name, no directory and no extension, it will echo just the filename. But
    doing text substitution on %0 will always use the full drive and path name
    to the file, including extension.

    The rest is left as an exercise for the reader :) Hope this helps,
    --
    Andrew McLaren
    amclar (at) optusnet dot com dot au
     
    Andrew McLaren, Jul 24, 2007
    #2
    1. Advertisements

  3. Matt Hickman

    Matt Hickman Guest

    On Jul 24, 1:42 am, "Andrew McLaren" <> wrote:

    Thanks, your sample was very helpful. Although I did find that the "/
    D" parameter works better for directory paths that contain spaces:

    REM =========== top ===========
    FOR /D %%I IN (%0) DO CD /d %%~dpI
    REM ========= bottom ===========

    Using quotes around "%0" caused me problems as well. (If you allow
    the "FOR" command to echo, you wll see that "%0" is implemented with
    quotes already)


    > This isn't really a bug inVista, as such; although it's probably a pretty
    > surprising "feature".
    >
    > When you run the Batch file "as Administrator", you are running it in a
    > different user context than the interactive user. Details of the environment
    > like "current directory" are tied to the user context. When you run the
    > batch file "as administrator" it takes the environment settings of the
    > administrator, not of the logged in user. The administrator doesn't know (or
    > care) what the current directory of user "MattH" is, it just goes ahead and
    > runs the batch file with its own environment.


    I am not sure that is the case. Do a "set" at the command line after
    you start cmd.exe selecting "Run as administrator", When I did, I
    found I was in the context of my own ID:
    ....
    USERNAME=Matt
    USERPROFILE=F:\Users\Matt
    ....
    Not quite like running a batch file in NT as a scheduled task using
    AT.EXE (talk about having to be explicit...)


    >
    > In programming terms - in the past, your coding effort has been made easier
    > by certain convenient assumptions, which however were not guarranteed to
    > always be there (ie current directory will be the location of the batch
    > file). So like any good programmer, you need to supply explicit values in
    > place of implicit assumptions, as "defensive programming".


    I explicitly hope that MS developers pay more attention to down-level/
    cross-level compatibility -- especially when there is no apparent
    reason to change system behavior.

    Again thanks for the help.

    --
    Matt Hickman
    Matt -a@t- thehickmans -d.ot- US
     
    Matt Hickman, Jul 25, 2007
    #3
  4. "Matt Hickman" <> wrote ...
    > Using quotes around "%0" caused me problems as well. (If you allow
    > the "FOR" command to echo, you wll see that "%0" is implemented with
    > quotes already)


    Actually, the quote marks you see there are inserted by Explorer. When you
    run the batch file from Explorer it internally puts quote marks around the
    string, I guess to deal with path names containing spaces. If you run the
    batch file from a command prompt, %0 is plain unadorned, wthout quotes.

    > I am not sure that is the case. Do a "set" at the command line after
    > you start cmd.exe selecting "Run as administrator", When I did, I
    > found I was in the context of my own ID:
    > ...
    > USERNAME=Matt
    > USERPROFILE=F:\Users\Matt


    Right. Actually, it gets more complicated :) and I kind of glossed over the
    complexity (didn't want to drown the post with superfluous information).

    If your Administrator account is explicitly enabled (ie, the user with SID
    S-1-5-21-2621085430-3789323321-3897899910-500) and you "Run as
    Administrator" then you get the environment of the Administrator. In this
    case you really do see:
    USERNAME=administrator
    USERPROFILE=C:\Users\administrator
    etc

    By default in Vista, the built-in Administrator account is disabled, and the
    "user" you first create at setup is a member of the Administrator's group.
    Except when you log in as this user, they don't get a full administrative
    security token straight way - Vista uses the concept of the "split token".
    When you elevate, either via Run As" or via an internal EXE manifest, then
    you get a full administrative token for the particular operation you
    elevated for. Exactly what bits of the user context remain the same and
    which vary is, I will concede, a bit mixed up. You'll probably find, for
    example, that any drives you had mapped as a "regular user" no longer work
    in the elevated context; because drive mappings aren't carried across to the
    elevated context (I shouldn't say "environment" because the "User
    Enviroment" strings are only one partial aspect of the user's total
    context).

    Some detailed info (admittedly a bit mind-numbing) here:
    http://msdn2.microsoft.com/en-us/library/bb530410.aspx

    > I explicitly hope that MS developers pay more attention to down-level/
    > cross-level compatibility -- especially when there is no apparent
    > reason to change system behavior.


    Well, there *was* a reason to change the behaviour - security. The behaviour
    you're seeing is a side effect of improved security in Vista. Microsoft
    certainly would not have bothered making these particular changes, unless
    there was a good reason (granted, in Vista they did seem to dick around with
    Explorer, Control Panel, etc, on a mere whim. But CMD is old, gnarly code,
    which no-one touches if they can help it). The security benefits may not be
    immediately obvious, but then, most of security is a subtle cat-n-mouse game
    which moved beyond the obvious, comon-sense stage, sometime around 1996.

    But wait! There's good news. CMD and batch files are bing superceded by
    PowerShell:
    http://www.microsoft.com/windowsserver2003/technologies/management/powershell/default.mspx.
    PowerShell is an entirely new comand processor and scritping language,
    designed from scratch. It is available for Vista and will be installed by
    default in Windows Server 2008 and Windows 7. CMD will still be there for
    legacy batch files; but PowerShell gives you vastly more control (in a
    consistent, understandable, predicable, composible manner) than CMD.

    Cheers,
    --
    Andrew McLaren
    amclar (at) optusnet dot com dot au
     
    Andrew McLaren, Jul 26, 2007
    #4
  5. On Mon, 23 Jul 2007 21:50:42 -0700, Matt Hickman

    >I have a batch script, setup.cmd, which depends on the default
    >directory, when it runs, being the directory where the script is
    >located. So if setup.cmd is located in c:\temp, that batch file
    >should run with c:\temp as its default directory.


    >Under Vista, setup.cmd needs to be run using the "run as
    >administrator" option. However, when I run it this way, the default
    >directory is \windows\system32.


    >what is the work-around for this bug?


    I would try using NT's extended batch file syntax to derive the
    location of the program file to define that as current, using the
    relevant syntax. Does mean not DOS/Win9x-compatible, tho.

    @Echo
    Echo This program is %0
    Echo It is running on drive %~d0
    Echo It is running from directory %~p0
    Echo We are currently here...
    CD
    Echo ...changing this location...
    %~d0
    CD %~dp0
    Echo We are now here:
    CD

    You can do a huge amount with this un-pretty but powerful syntax.
    Play with %~?0 where ? = x n s t z d p etc. or do the Help thing.




    >--------------- ----- ---- --- -- - - -

    To one who only has a hammer,
    everything looks like a nail
    >--------------- ----- ---- --- -- - - -
     
    cquirke (MVP Windows shell/user), Jul 26, 2007
    #5
  6. Matt Hickman

    Guest

    , Apr 19, 2014
    #6
    1. Advertisements

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Similar Threads
  1. dNi
    Replies:
    3
    Views:
    868
    Ronald Fisher
    Feb 28, 2007
  2. slimbim

    Regular Run As... option (not Run As Administrator)

    slimbim, Mar 21, 2007, in forum: Windows Vista Administration
    Replies:
    2
    Views:
    499
    ILYNS
    Oct 20, 2008
  3. ching

    WMP needs "run as administrator" to run, why?

    ching, Jun 24, 2007, in forum: Windows Vista Administration
    Replies:
    0
    Views:
    512
    ching
    Jun 24, 2007
  4. bilglas

    "Run as Administrator" ... make default??

    bilglas, Mar 7, 2007, in forum: Windows Vista General Discussion
    Replies:
    20
    Views:
    572
    Andrew McLaren
    Jul 9, 2007
  5. RoaringLambs
    Replies:
    6
    Views:
    1,605
  6. Chamber
    Replies:
    1
    Views:
    503
    Gary VanderMolen
    Jul 10, 2009
  7. Elohim

    Volume level changes when track position changes

    Elohim, Dec 30, 2004, in forum: Windows Media Player
    Replies:
    1
    Views:
    391
    Chris Lanier [MVP]
    Dec 31, 2004
  8. tankman1989
    Replies:
    1
    Views:
    1,591
    Flavius
    Sep 6, 2009
Loading...