Fixed In batch files, %0 now evaluates to the absolute path

[nickles]

Since 17, in batch files %0 now expands to the batch file's absolute path, and no longer to just the file name. This breaks some functionality here...

 

[rconn]

I have changed v17 in build 57 to behave the same way as v16.

HOWEVER -- what you're doing is a really, really bad idea. V16 (and all previous versions, and CMD) never expanded %0 to just the file name. They expanded it to whatever was on the command line, be it the file name (with or without extension), partial pathname, or full path. What you're doing means your batch file will break if you run it from anywhere other than the current directory, or if you try to run it from a shortcut.

 

[w_krieger]

I avoid using %0, because you get things like mybatch vs mybatch.bat. It's really what the user types in. Use %_batchname and some of the fancy functions in 4nt to get the desired format.

 

[nickles]

@Rex

Thanks!

 

[Tech.batch]

@nickles @rconn Hi Nickles, don't know if you are still interested in this, but it appears that it is broken again in V 21

Sample batch file to show all you ever wanted to know about the running batch, but didn't know how to ask.

@echo off
for /f "tokens=* delims=?" %%d in ('cd ') do set start_drv=%%~dd& set start_dir=%%~pd
echo Starting drive = %start_drv%
echo Starting directory = %start_dir%
for /f "tokens=* delims=?" %%d in ('cd ') do set start_dir=%%~pd
echo Starting directory = %start_dir%
for /f "tokens=* delims=?" %%d in ('cd ') do set start_dir=%%d
echo Starting directory = %start_dir%
echo Starting command line = %0 %*
echo %%0 = %0
echo Running batch file name = %~nx0
echo Location of Running batch file name = %~dp0
echo FQN for Running batch file name = %~dpnx0

Output when run in IDE 21

Starting drive = C:
Starting directory =
Starting directory = \Program Files\JPSoft\
Starting directory = C:\Program Files\JPSoft\TCMD21
Starting command line = J:\test.bat par1 par2
%0 = J:\test.bat
Running batch file name = test.bat
Location of Running batch file name = J:\
FQN for Running batch file name = J:\test.bat

TCC is showing the FQN for %0 again.
Also it appears TCC can't handle the 2nd command "& set start_dir=%%~pd" on the "for /f" line and fails to execute it
And when run as a single command, does not get the correct value for the path - it truncates the \TCMD21 folder of the path

Here is the output when run in CMD

Starting drive = j:
Starting directory = \
Starting directory = \
Starting directory = j:\test
Starting command line = test par1 par2
%0 = test
Running batch file name = test.bat
Location of Running batch file name = j:\test\
FQN for Running batch file name = J:\test\test.bat

Strangely, CMD can extract the drive name from the "CD" output, but it can't extract the path !!

Errol

 

[mikea]

I suppose this thread concerns compatibility with cmd.exe (I haven't read all of it). That aside, with respect to the previous comment I can't help wondering: Why be saddled with some of cmd.exe's most painful 'features' — having to use clumsy 'for' loops to derive certain information. for example — when TCC's own solutions are so much simpler? For example:

echo Starting drive: %_disk:
echo Starting directory: %_cwp\
echo %%0, literally: %0
echo %%0, via 'batchname variable': %_batchname
echo Starting command line: %cmdline

The above lines produce the following screen display (not intended to mirror your own commands precisely):

Starting drive: C:
Starting directory: \TakeCommand20\SupportFiles\
%0, literally: test.btm
%0, via 'batchname variable': C:\TakeCommand20\SupportFiles\test.btm
Starting command line: test.btm a b c

I'm behind schedule updating and I'm running v.20. Perhaps the results differ slightly in the latest version.

When I've had to write semi-complex batch files that require maximum compatibility with both systems, I've avoided the compatibility problem entirely. Instead I've inserted a simple test near the start to detect TCC. If it's detected, the batch file goes to a label where TCC-specific (.btm only) commands are used. Yes, there's duplication of effort. But the advantages are that 1) I never have to worry about perfect compatibility with cmd.exe and 2) I can take advantage of TCC commands that would be very difficult or even impossible in a cmd.exe environment. The idea of not using "iff/then/endiff" or "do" loops or "switch/endswitch" when I could use them — too painful to contemplate!

 

[rconn]

@nickles @rconn Hi Nickles, don't know if you are still interested in this, but it appears that it is broken again in V 21

TCC is showing the FQN for %0 again.

That's not quite accurate.

The contents of %0 depend on how you invoke the batch file (partial name, full name, partial path, full path, etc.), and is identical in both TCC and CMD. What you see in the IDE is because the batch debugger starts the batch file with a full path + full name. There's nothing wrong with starting a batch file with the full pathname, and if your batch files choke on that you might want to consider rewriting them (as they'll also fail when started from Explorer).

 

[rconn]

@nickles @rconn
Sample batch file to show all you ever wanted to know about the running batch, but didn't know how to ask.

@echo off
for /f "tokens=* delims=?" %%d in ('cd ') do set start_drv=%%~dd& set start_dir=%%~pd
echo Starting drive = %start_drv%
echo Starting directory = %start_dir%
for /f "tokens=* delims=?" %%d in ('cd ') do set start_dir=%%~pd
echo Starting directory = %start_dir%
for /f "tokens=* delims=?" %%d in ('cd ') do set start_dir=%%d
echo Starting directory = %start_dir%
echo Starting command line = %0 %*
echo %%0 = %0
echo Running batch file name = %~nx0
echo Location of Running batch file name = %~dp0
echo FQN for Running batch file name = %~dpnx0

Also it appears TCC can't handle the 2nd command "& set start_dir=%%~pd" on the "for /f" line and fails to execute it
And when run as a single command, does not get the correct value for the path - it truncates the \TCMD21 folder of the path

Your syntax is incorrect (for both CMD and TCC). If you have a compound command in a FOR, you need to use a command group:

for /f "tokens=* delims=?" %%d in ('cd ') do (set start_drv=%%~dd & set start_dir=%%~pd)

CMD is only appearing to work without the command group because it expands the entire line on the first SET, and then executes the second SET outside of the FOR loop. That's certainly not behavior that should be expected, encouraged or relied upon.

 

[Tech.batch]

The contents of %0 depend on how you invoke the batch file (partial name, full name, partial path, full path, etc.), and is identical in both TCC and CMD. What you see in the IDE is because the batch debugger starts the batch file with a full path + full name.

OK. I couldn't find any doco on how the debugger is "fed".
@rconn I presume the command line use to start the batch file can't be modified ?

Your syntax is incorrect (for both CMD and TCC).

@rconn Thanks for the correction Rex - I missed that when I collapsed the command group of the "FOR" down to a single line

Errol

 

[Tech.batch]

I can't help wondering: Why be saddled with some of cmd.exe's most painful 'features' — having to use clumsy 'for' loops to derive certain information. for example — when TCC's own solutions are so much simpler?

@mikea I am only on the third day of evaluating Take Command's IDE & debugger and already up to my Fourth "BUG report"
The batch files I write are not for use by me on my PC, but for servers in most of 40+ sites that I monitor and maintain.
If I decide the IDE & debugger are going to be useful for this work, then I will look at what TCC features may be helpful.

Errol