Elevate without losing the working directory?

"Art Braver" <artbraver@discussions.microsoft.com> wrote in message
news:7553a3dfdji9spv0hgnv39eqlf2mqh35e6@news.micro soft.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.micro soft.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!

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