Vista - 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?

> 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?

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

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

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

"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?

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

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

Thanks for your help!

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!
>--------------- ---- --- -- - - - -