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. #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

  3. #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

  4. #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

  5. #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

  6. #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

  7. #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

  8. #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
Running batch files as administrator change working directory
Hi, if you start a batch file from Explorer the working directory is the directory which holds the file. If you start a batch file from a...
Vista General
Losing rights to "Shared Virtual Networks" directory
Hi all, I run various VMs under a domain user account ("VMRun") set up specifically for the purpose. The VMRun user has Modify/Write rights at...
Virtual Server
elevate privilege
I use powershell for most operations and would like to know if there's a way to execute a program with elevated privileges. For instance, is there a...
PowerShell
UAC can not elevate
Hello I am unable to perform any Administrative tasks becasue my only true Administrator was previously hidden from the Welcome Screen and remains...
Vista account administration
Commands not working inside directory with square brackets in its
I have noticed that some commands don't work when the name of the current directory includes square brackets, for example . If I type DIR I see...
PowerShell
Parameter names for a New-Process Cmdlet: item name and working directory
The New-Process cmdlet I'm working on has a couple of parameters that I find awkward to name correctly using the PowerShell guidance; the parameters...
PowerShell
Getting/Setting filesystem working directory
Since there are some occasions where the location cmdlets don't work well - for example, relative path names used in functions - I've got a couple...
PowerShell