Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

%~dp0 in Windows 7

2,237 views
Skip to first unread message

alexsupra

unread,
Dec 19, 2011, 2:49:45 PM12/19/11
to
experiments show that Windows 7 cmd has bug or special feature when
processing of commands like

cd /d "%~dp0"

that aim identify the directory where the current script (%~nx0) is
located.
Windows 7 cmd returns the path of %cd%?

Is it possible for Windows 7 to refer the directory where the current
script is located?

Tom Lavedas

unread,
Dec 19, 2011, 5:30:33 PM12/19/11
to
When you issue the name of a procedure that is located elsewhere than
in the currently active folder, but rely on the PATH to provide the
correct location, that formulation will always return the local folder
- unless the full pathspec was provided in calling the procedure.
(whew - I'm out of breath - that was a long one. ;-). The work around
is to search the path for the correct location, something like
this ...

for %%P in (. %path%) do if exist "%%P\%~nx0" set "BatPathspec=%%~fP\
%~nx0"

Unfortunately, in the age Windows, the "Program Files" and "Program
Files (86)" screw this approach up, because of the embeded spaces.
The real culprit is the closing paren. Unless you put something in a
"Program Files" location, you might get away with replacing the
closing paren with something else, like ...

@echo off
for %%P in (. %path:)=^)%) do if exist "%%P\%~nx0" set "BatPathspec=%
%~fP\%~nx0"
set batpathspec
____________________________
Tom Lavedas

Todd Vargo

unread,
Dec 20, 2011, 1:19:33 AM12/20/11
to
Works correctly for me in Windows 7.

Try inserting an ECHO in front of the command to verify variable
expansion is what you expect. Does the user account have permission to
make that folder current?

--
Todd Vargo
(Post questions to group only. Remove "z" to email personal messages)

Frank P. Westlake

unread,
Dec 20, 2011, 9:55:43 AM12/20/11
to
On 2011-12-19 22:19, Todd Vargo wrote:
> Works correctly for me in Windows 7.

It also works in my unadulterated version of Windows 7.

> Try inserting an ECHO in front of the command to verify variable
> expansion is what you expect. Does the user account have permission to
> make that folder current?

Also remember that if your script is using SETLOCAL the current
directory will revert to the previous directory after the ENDLOCAL (or EOF).

Frank

Todd Vargo

unread,
Dec 20, 2011, 11:51:31 AM12/20/11
to
That is a good tip to know when using SETLOCAL in subroutines. Too bad
OP did not post code for use to try to reproduce the problem.

vjp...@at.biostrategist.dot.dot.com

unread,
Dec 24, 2011, 12:11:34 AM12/24/11
to
hm.. I've been trying to add legacy DOS apps to my PortableApps using bat2exe
and ~dp0. I got one exe from my batch to work correctly in XP and when I
tried it on someone else's Win 7 machine it didn't start.. not sure I
understand what happened.. Curiously on another program the ~dp0 did not work
as an exe but was fine as a bat, and the it worked fine as %CD%.

clues?


- = -
Vasos Panagiotopoulos, Columbia'81+, Reagan, Mozart, Pindus, BioStrategist
http://www.panix.com/~vjp2/vasos.htm
---{Nothing herein constitutes advice. Everything fully disclaimed.}---
[Homeland Security means private firearms not lazy obstructive guards]
[Urb sprawl confounds terror] [Phooey on GUI: Windows for subprime Bimbos]




foxidrive

unread,
Dec 24, 2011, 12:20:36 AM12/24/11
to
On 24/12/2011 16:11, vjp...@at.BioStrategist.dot.dot.com wrote:
> hm.. I've been trying to add legacy DOS apps to my PortableApps using bat2exe
> and ~dp0. I got one exe from my batch to work correctly in XP and when I
> tried it on someone else's Win 7 machine it didn't start.. not sure I
> understand what happened.. Curiously on another program the ~dp0 did not work
> as an exe but was fine as a bat, and the it worked fine as %CD%.
>
> clues?

bat2exe from which era?

If it's not written for NT series batch commands then it will not understand them.



--
Regards,
Mic

vjp...@at.biostrategist.dot.dot.com

unread,
Dec 24, 2011, 12:45:56 AM12/24/11
to
f2ko.de v1.5.1 - should be current
(I know, i was using bat2exe which made com files before this)

*+-bat2exe from which era?

*+-If it's not written for NT series batch commands then it
will not understand them.

Remember I said it worked on XP. The bat commands I used can be found in an
old thread started by me on hostdrive.

foxidrive

unread,
Dec 24, 2011, 1:31:47 AM12/24/11
to
On 24/12/2011 16:45, vjp...@at.BioStrategist.dot.dot.com wrote:
> f2ko.de v1.5.1 - should be current

V 1.6.0.0 is current. There is no documentation about what OS it supports and I suspect it is merely a wrapper.

> (I know, i was using bat2exe which made com files before this)
>
> *+-bat2exe from which era?
>
> *+-If it's not written for NT series batch commands then it
> will not understand them.
>
> Remember I said it worked on XP.

What worked. And what didn't.

> The bat commands I used can be found in an
> old thread started by me on hostdrive.

We'd have to see the precise code you are trying to use - one reason is that anyone who is interested could try it out and confirm the issue.



--
Regards,
Mic

foxidrive

unread,
Dec 24, 2011, 11:00:08 AM12/24/11
to
On 24/12/2011 16:11, vjp...@at.BioStrategist.dot.dot.com wrote:
> hm.. I've been trying to add legacy DOS apps to my PortableApps using bat2exe
> and ~dp0. I got one exe from my batch to work correctly in XP and when I
> tried it on someone else's Win 7 machine it didn't start..

If the bat2exe is a wrapper then the batch file is being extracted and launched by the wrapper - it may not have permissions in Win7 for whatever it is doing, such as writing to a specific folder.

> not sure I
> understand what happened.. Curiously on another program the ~dp0 did not work
> as an exe but was fine as a bat, and the it worked fine as %CD%.
>
> clues?

To get pertinent answers then we here would need to see your code.


Without code it's like asking "what's wrong with my spelling" and not showing the written page.


--
Regards,
Mic

vjp...@at.biostrategist.dot.dot.com

unread,
Dec 24, 2011, 6:47:10 PM12/24/11
to
Correct! With apologies. I found that I had deleted the BAT file that led to
the successful EXE in XP, which is why I mentioned I got it by googling my
old hostdrive posts to this newsgroup.. something like this worked on XP but
not w7:

SET dogpath=%~d0\dog\
SET PATH=%PATH%;%dogpath%
DOG.EXE -switches %dogpath%UTIL\

But in W7 it just ran a DOS screen that quickly went away

Again, it was a borrowed machine

foxidrive

unread,
Dec 24, 2011, 11:09:30 PM12/24/11
to
On 25/12/2011 10:47, vjp...@at.BioStrategist.dot.dot.com wrote:
> Correct! With apologies. I found that I had deleted the BAT file that led to
> the successful EXE in XP, which is why I mentioned I got it by googling my
> old hostdrive posts to this newsgroup.. something like this worked on XP but
> not w7:

> SET dogpath=%~d0\dog\
> SET PATH=%PATH%;%dogpath%
> DOG.EXE -switches %dogpath%UTIL\
>
> But in W7 it just ran a DOS screen that quickly went away
>
> Again, it was a borrowed machine

Try replicating the issue with the batch file you posted above.



--
Regards,
Mic

Todd Vargo

unread,
Dec 25, 2011, 12:15:08 AM12/25/11
to
On 12/24/2011 6:47 PM, vjp...@at.BioStrategist.dot.dot.com wrote:
> Correct! With apologies. I found that I had deleted the BAT file that led to
> the successful EXE in XP, which is why I mentioned I got it by googling my
> old hostdrive posts to this newsgroup.. something like this worked on XP but
> not w7:
>
> SET dogpath=%~d0\dog\
> SET PATH=%PATH%;%dogpath%
> DOG.EXE -switches %dogpath%UTIL\
>
> But in W7 it just ran a DOS screen that quickly went away
>
> Again, it was a borrowed machine

Try the following to assist with debugging the problem.

To prevent the cmd window from closing when double clicking the batch,
add a PAUSE statement following the last command in the batch. This will
give you a chance to read any error message that may have been
displayed. The alternative method to this is to run the batch from the
command line. If there is any EXIT commands in the batch, place a PAUSE
command before them.

Secondly, you need to verify that there are no issues with anything
already stored in PATH. Try reversing the order to move %dogpath% to the
beginning of the path and see if there is any difference.

SET PATH=%dogpath%;%PATH%

Frank P. Westlake

unread,
Dec 25, 2011, 8:56:13 AM12/25/11
to
On 2011-12-24 15:47, vjp...@at.BioStrategist.dot.dot.com wrote:
> SET dogpath=%~d0\dog\
> SET PATH=%PATH%;%dogpath%
> DOG.EXE -switches %dogpath%UTIL\

That works fine in Windows 7 so try the debugging that Todd suggests.

Frank

Sven Köhler

unread,
Jan 1, 2012, 11:07:19 PM1/1/12
to
Am 19.12.2011 20:49, schrieb alexsupra:
> experiments show that Windows 7 cmd has bug or special feature when
> processing of commands like
>
> cd /d "%~dp0"
>
> that aim identify the directory where the current script (%~nx0) is
> located.
> Windows 7 cmd returns the path of %cd%?

Can you please explain in which case %~dp0 is not equal to the directory
which contains the currently executed script? You're scaring me, because
some of my scripts rely on that (and probably out there do so too).


Regards,
Sven

foxidrive

unread,
Jan 2, 2012, 12:00:00 AM1/2/12
to
In this case it will show the current drive and folder, where you might logically expect it to show the drive and path of each of the files within the folders in the current subdirectory.

Tested in XP Pro SP3


@echo off
for /f "delims=" %%a in ('dir /b /ad') do (
for /f "delims=" %%b in ('dir "%%a" /b') do (
echo %%~dpb
)
)
pause





--
Regards,
Mic

Todd Vargo

unread,
Jan 2, 2012, 4:12:28 PM1/2/12
to
Unfortunately, OP has yet to respond with additional information or a
complete batch exhibiting the so-called bug which we can reproduce.
(Unless OP responded as vjp2 which indicates a bat2exe related issue)
0 new messages