How to? debugging files that use CALL command - possible??

[Vasilich]

Hi.
I started evaluating TakeCommand (batch debugger part), but can't get it working when one batch file calls another one:

call 2

- console shows me

TCC: C:\tst\1.bat [3]  Unknown command "2"

though 2.bat is in the same directory where the main batch file is.

i attached files for fast check - without TakeCommand , using pure windows command interpreter, it works as expected, calling 2.bat and returning back to main batch.

Is it possible to debug such batch files in TakeCommand?

 

[rconn]

Yes, you can CALL batch files from within the batch debugger. You can also single-step into them (if you use the step into and not the step over option).

However, the batch debugger isn't necessarily running in the same directory as the TCC session that invokes it, particularly if you have something in your TCSTART that is setting the default directory. (Not a very good idea if you're doing that for transient sessions!) If you put a CD or CDD at the beginning of your batch file to force the correct working directory, everything should work as expected.

 

[Vasilich]

thatks for reply, Rex. Actually i just want to debug my batch files on my PC, and all other use them without need to install TCC. And as CDD is not supported by windows command shell, this is not an option for me. I will try tomorrow with CD. But what arguments shall i give to CD to work inside TakeCommand debugger? And - how do i learn TakeCommand to automatically use directory of editing file as current? (at least RunningSteps and PrimalScript do that :) )

 

[rconn]

You can either switch to the directory you want to use as the default before starting BDEBUGGER or IDE, or you can put a "CD /D drive:path" argument at the beginning of your batch files, which is supported in TCC and CMD. Probably a good idea anyway, unless you know that nobody is ever going to change directories before (or during) running a batch file.

The Take Command debugger doesn't automatically switch to the directory containing the batch file when debugging because:

1) The debugger allows editing multiple batch files through the tabbed interface, and it would be highly confusing to users for it to be (invisibly) switching to different directories.
2) Users frequently (probably even mostly) want to execute batch files from another directory (either explicitly or via the PATH). Changing to the directory containing the batch files could mean the batch file then couldn't find its files.