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!