Windows Vista Forums

Elevate without losing the working directory?

  1. #1


    Michael A. Covington Guest

    Elevate without losing the working directory?

    I'm trying to port to Vista a large set of software installation scripts
    (.BAT files) that we've been using with XP and earlier versions, and the
    following thing is driving me batty:

    Whenever a .BAT file is elevated (to use administrator privileges), it loses
    track of its working directory and instead runs in %windir%\system32.

    That means it can no longer locate the files that are in the directory with
    it.

    I've tried elevation by right-clicking and choosing "Run As Administrator,"
    and also by using the "runas" verb argument of ShellExecute in JScript.
    Both give the same result. Passing ShellExecute a directory argument
    doesn't help.

    Is there any way to elevate (in order to be able to write in
    %allusersprofile%) without losing track of the working directory? The main
    thing we need to do in the scripts that is tricky is move around some of the
    items on the Start Menu. Maybe there is a separate utility for munging the
    Start Menu?



      My System SpecsSystem Spec

  2.   


  3. #2


    Art Braver Guest

    Re: Elevate without losing the working directory?

    > Whenever a .BAT file is elevated (to use administrator privileges), it loses
    > track of its working directory and instead runs in %windir%\system32.


    What happens when you use
    cd /d %~dp0
    as the first line of the bat file?


      My System SpecsSystem Spec

  4. #3


    Michael A. Covington Guest

    Re: Elevate without losing the working directory?

    "Art Braver" <artbraver@discussions.microsoft.com> wrote in message
    news:7553a3dfdji9spv0hgnv39eqlf2mqh35e6@news.microsoft.com...
    >> Whenever a .BAT file is elevated (to use administrator privileges), it
    >> loses
    >> track of its working directory and instead runs in %windir%\system32.

    >
    > What happens when you use
    > cd /d %~dp0
    > as the first line of the bat file?


    Interesting question! I'll try it. (Can't do it on this machine just at
    this moment.)

    I take it %~dp0 is the full path of the .bat file itself?

    Thanks.



      My System SpecsSystem Spec

  5. #4


    Michael A. Covington Guest

    Re: Elevate without losing the working directory?


    "Art Braver" <artbraver@discussions.microsoft.com> wrote in message
    news:7553a3dfdji9spv0hgnv39eqlf2mqh35e6@news.microsoft.com...
    >> Whenever a .BAT file is elevated (to use administrator privileges), it
    >> loses
    >> track of its working directory and instead runs in %windir%\system32.

    >
    > What happens when you use
    > cd /d %~dp0
    > as the first line of the bat file?


    It worked. To be precise:

    setlocal enableextensions
    cd /d "%~dp0"

    This goes into the long "prologue" that I put at the beginning of each of my
    install.bat files to help incoming students configure their laptops. The
    prologue checks a lot of things (suitable Windows version, running with
    adequate privileges to install software, etc.) and gives meaningful error
    messages. Eventually I'll publish the whole prologue.

    Trivia: %~dp0 is a path including the final \, but %cd% is a path not
    including the final \. So even when they are the same path, they are not
    string-identical.





      My System SpecsSystem Spec

  6. #5


    cquirke (MVP Windows shell/user) Guest

    Re: Elevate without losing the working directory?

    On Sun, 29 Jul 2007 18:23:29 -0400, "Michael A. Covington"
    >"Art Braver" <artbraver@discussions.microsoft.com> wrote in message


    >>> Whenever a .BAT file is elevated (to use administrator privileges), it
    >>> loses track of its working directory and instead runs in %windir%\system32.

    >>
    >> What happens when you use
    >> cd /d %~dp0
    >> as the first line of the bat file?

    >
    >It worked. To be precise:
    >
    >setlocal enableextensions
    >cd /d "%~dp0"
    >
    >This goes into the long "prologue" that I put at the beginning of each of my
    >install.bat files to help incoming students configure their laptops. The
    >prologue checks a lot of things (suitable Windows version, running with
    >adequate privileges to install software, etc.) and gives meaningful error
    >messages. Eventually I'll publish the whole prologue.


    Sounds v.nice ;-)

    >Trivia: %~dp0 is a path including the final \, but %cd% is a path not
    >including the final \. So even when they are the same path, they are not
    >string-identical.


    That's a significant thing! Also, look for anomalies that arise when
    the root is used, e.g. you often find contexts that return no trailing
    \ will break when the root uses a trailing \ (as it has to), e.g...

    Set Dir=C:\Some\Path
    Set File=SomeName.ext
    Set FileSpec=%Dir%\%File%
    Echo %FileSpec%

    Set Dir=C:\
    Set File=SomeName.ext
    Set FileSpec=%Dir%\%File%
    Echo %FileSpec%

    The interesting thing is that Cmd.exe appears to tolerate all sorts of
    syntax botch-ups, e.g...

    Dir C:\Some\\Path
    Dir C:\Some\"\Path"
    Dir C:\Some\\"\Path"
    Dir C:\Some\\\\\\\\Path

    .....prolly with construct-a-filespec issues in mind ;-)

    If the above holds beyond my simple testing with Dir commands in
    Cmd.exe on XP SP2, then it's best to routinely err on the side of "too
    many delimiters" - but even here, there are caveats...

    Dir C:\\Some\\Path ("the network path was not found")

    ....and ADS syntax, such as C:\Some\Path\File:name

    Believe me, you do not want to spawn ADS !

    There's extended syntax to slice strings, so for more robustness, you
    can force drive letters to be drive letters (at least syntactically).
    That will give you valid syntax, at the risk of incorrect paths...

    Input: C:\Blob \Some\New\Path
    Output: C:\Some\New\Path

    Input: Blob \Some\New\Path
    Output: B:\Some\New\Path

    Input: \Blob \Some\New\Path
    Output: \:\Some\New\Path

    ....so better to use %~d to pick out the drive letter, perhaps. Though
    what that will default to for variable values like \Some\Path is
    something that you'd have to consider, too.



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

    First, the good news: Customer feedback has
    been clear and unambiguous.
    >--------------- ----- ---- --- -- - - -


      My System SpecsSystem Spec

  7. #6


    Michael A. Covington Guest

    Re: Elevate without losing the working directory?


    "cquirke (MVP Windows shell/user)" <cquirkenews@nospam.mvps.org> wrote in
    message news:jf13b3pj4e1d6j93o19lbs1iu2l82529sl@4ax.com...


    > ...and ADS syntax, such as C:\Some\Path\File:name
    >
    > Believe me, you do not want to spawn ADS !


    What is ADS? The system for multiple "streams" in a file?



      My System SpecsSystem Spec

  8. #7


    Michael A. Covington Guest

    Re: Elevate without losing the working directory?

    I've blogged the complete kluge -- er I mean solution -- at:

    http://www.covingtoninnovations.com/.../0708/#070805B

    Thanks for your help!



      My System SpecsSystem Spec

  9. #8


    cquirke (MVP Windows shell/user) Guest

    Re: Elevate without losing the working directory?

    On Sat, 4 Aug 2007 10:07:19 -0400, "Michael A. Covington"
    >"cquirke (MVP Windows shell/user)" wrote in


    >> ...and ADS syntax, such as C:\Some\Path\File:name
    >>
    >> Believe me, you do not want to spawn ADS !

    >
    >What is ADS? The system for multiple "streams" in a file?


    Alternate Data Streams, yes - useful for "supporting" MacOS's
    "resource forks", but also as a hiding place for malware.

    The problems with ADS, are:
    - nothing in the shell ever displays them
    - they can contain code
    - when running, task manager only reports the base file name
    - any file check of the base file will pass MD5 etc. as "OK"



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

    Saws are too hard to use.
    Be easier to use!
    >--------------- ---- --- -- - - - -


      My System SpecsSystem Spec


Elevate without losing the working directory?
Similar Threads
Thread Forum
Losing rights to "Shared Virtual Networks" directory Virtual Server
UAC can not elevate Vista account administration
Commands not working inside directory with square brackets in its PowerShell
Parameter names for a New-Process Cmdlet: item name and working directory PowerShell
Getting/Setting filesystem working directory PowerShell