Windows Vista Forums
Vista Forums Home Join Vista Forums Tech Publications Windows 7 Forum Vista Tutorials Webcasts Tags

Welcome to Vista Forums we are your forum for Windows Vista help and discussion. Whether you need help or just want to post an idea you have on Vista, this is the forum for you.
Register at Vista forums...the world biggest Windows Vista resource Join Vista Forums Now

Go Back   Vista Forums > Vista Newsgroups > Vista security

Elevate without losing the working directory?

Update your Vista Drivers
Reply
 
Thread Tools Display Modes
Old 07-19-2007   #1 (permalink)
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
Old 07-21-2007   #2 (permalink)
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
Old 07-24-2007   #3 (permalink)
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
Old 07-29-2007   #4 (permalink)
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
Old 08-02-2007   #5 (permalink)
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
Old 08-04-2007   #6 (permalink)
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
Old 08-04-2007   #7 (permalink)
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
Old 08-05-2007   #8 (permalink)
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
Reply
Update your Vista Drivers

Thread Tools
Display Modes



Similar Threads
Thread Thread Starter Forum Replies Last Post
Running batch files as administrator change working directory corradolab Vista General 1 01-07-2008 10:41 AM
UAC can not elevate SimonW Vista account administration 7 05-27-2007 03:35 PM
Commands not working inside directory with square brackets in its Gabriele G. Ponti PowerShell 5 12-02-2006 01:21 AM
Parameter names for a New-Process Cmdlet: item name and working directory Alex K. Angelopoulos [MVP] PowerShell 1 09-18-2006 01:59 PM
Getting/Setting filesystem working directory Alex K. Angelopoulos [MVP] PowerShell 4 08-16-2006 03:00 PM


Complimentary Industry Resources

Vista Forums has joined forces with TradePub.com to offer you a new, exciting, and entirely free professional resource. Visit http://vistax64.tradepub.com today to browse our selection of complimentary Industry magazines, white papers, webinars, podcasts, and more across 34 industry sectors. No credit cards, coupons, or promo codes required. Try it today!




Vista Forums is an independent web site and has not been authorized,
sponsored, or otherwise approved by Microsoft Corporation.
"Windows Vista", the Start Orb, and related materials are trademarks of Microsoft Corp.
© Designer Media 2005-2008

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51