Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

How to? Show the values of batch variables on the TCC screen

Jul
20
0
Now that I have reported the "Strange Unexpected Features I found in my 1st hour of testing the demo, I have been looking at the documented features and general operation.
What I find a difficulty with, is that when the TCC screen shows the batch line to be executed, sometimes the batch variables are shown as un-expanded (e.g. if "%md5%"=="")
and sometimes as expanded (e.g. find ",""e967594941e290ac557d4f77a1b02025""," "All_TRS80.lst" for the line "find %md5%"," "All_TRS80.lst"
This makes debugging a repeating sequence much harder because you can't scroll back through the screen and see the values used at each iteration.
Have look at the screen dump below and try to figure out what the value of %dups% is at each instance of :-
if %dups% LSS 2
In an normal CMD environment, the variables are always replaced by their value before the line is echoed to the screen (unless inhibited by delayed expansion)

So, my question is :-
Is there some method to make the TCC screen show the variable's value, instead of it's name, or do I have to add extra code like :-
set val=%dups% & if %dups% LSS 2
just to show the variable's value at the time of the iteration ??

I have searched the Help and on-line documentation, but can't find any mention of parameters or facilities for the Debugger screen.

set /A dups=0
if %2=="casrdr80.bas" pause
find ",""e967594941e290ac557d4f77a1b02025""," "All_TRS80.lst" > dups.chk
find /c ",""e967594941e290ac557d4f77a1b02025""," dups.chk > dups.cnt
for /f "tokens=2 delims=:" %%m in ('type dups.cnt') do set /A dups=%%m
if %dups% LSS 2 goto :eof
set file="diskdisk.txt"
set md5=a3713913a2d1937f92271cf3af1d659b
if "%md5%"=="" goto :eof
set /A dups=0
if %2=="casrdr80.bas" pause
find ",""a3713913a2d1937f92271cf3af1d659b""," "All_TRS80.lst" > dups.chk
find /c ",""a3713913a2d1937f92271cf3af1d659b""," dups.chk > dups.cnt
for /f "tokens=2 delims=:" %%m in ('type dups.cnt') do set /A dups=%%m
if %dups% LSS 2 goto :eof
set file="diskio.bas"
set md5=9b84cbfb12e1ec8d5782e0e6cd43750e
if "%md5%"=="" goto :eof
set /A dups=0
if %2=="casrdr80.bas" pause
find ",""9b84cbfb12e1ec8d5782e0e6cd43750e""," "All_TRS80.lst" > dups.chk
find /c ",""9b84cbfb12e1ec8d5782e0e6cd43750e""," dups.chk > dups.cnt
for /f "tokens=2 delims=:" %%m in ('type dups.cnt') do set /A dups=%%m
if %dups% LSS 2 goto :eof
set /a dups=0
find /c ",""9b84cbfb12e1ec8d5782e0e6cd43750e""," dups_list.csv > dup_done.chk
for /f "tokens=2 delims=:" %%d in ('type dup_done.chk') do set /a dups=%%d
if %dups% NEQ 0 goto :eof
for /f "tokens=* delims=? skip=2 " %%f in ('type dups.chk') do call :count_dups %%f
set file=diskio.bas
if not "%file:~0,3%"=="(d)" ( if not "%file:~0,3%"=="(x)" ( if not "%file:~0,3%"=="(j)" ( if not "%file:~0,3%"=="(u)" ( if not "%file:~0,3%"=="(b)" set /a dups+=1 ) ) ) )
goto :eof
 
If your desire is to debug your script, why not use BDEBUGGER? You can monitor as many or as few variables as you want.
 
Not sure what you're referring to here -- if you're talking about having ECHO ON in your batch file, TCC will always display the line after any alias or variable expansion and redirection.

If you're talking about BDEBUGGER, TCC always shows the original batch file (unexpanded) in the edit window. If you want to see the variables, look at the Watch, Modified, Environment, or Batch Parameters tabs. Or hover the mouse over a variable name. Or Alt-F11 to evaluate variables (or expressions).
 
@Rex - I recall back in the dayes the support forum was one on CIS - there was a DOC file that had the various key mappings for the command line, and similar. Is there an updated one for BDebugger, command line, etc, please?
 
@samintz, @Rex

If your desire is to debug your script, why not use BDEBUGGER? You can monitor as many or as few variables as you want.

What is a BDEBUGGER. Is this something different to the "Debugger" screen attached to the IDE ??

TCC always shows the original batch file (unexpanded) in the edit window

Yes, I have the source batch file in the edit window.
I am trying to get the "Debugger" screen to show the content of the variables when used at run time.

I am already using the Watch list, but it has 2 significant shortcomings :-
1st (and by design) it only shows the current value of the variable, not what it was the 5 times it was previously used.
2nd (a bug) I have already found that the Watch list is not reliable. See my previous post "Bug Strange Unexpected "features" in the Debugger" in the Support forum - specifically the first part about "Watch list corruption"

The purpose of my request was to be able see what the value is at each step of the batch file when reviewing progress up to a break point.
When you are at the break point, you can only see the current values of the variables in the Watch list.

Here is a sample batch

set var=%1
set /a count=%var% + 0
:loop
set now=%count%
set /a count+=1
if %count% LSS 5 goto loop


The following is the output copied from the TCC screen

set var=
set /a count= + 0
set now=0
set /a count+=1
if %count% LSS 5 goto loop
set now=1
set /a count+=1
if %count% LSS 5 goto loop
set now=2
set /a count+=1
if %count% LSS 5 goto loop
set now=3
set /a count+=1
if %count% LSS 5 goto loop
set now=4
set /a count+=1
if %count% LSS 5 goto loop


Note the "IF" line is shown the same for each iteration of the loop
And this is copied from the CMD window

j:\>test
j:\>set var=
j:\>set /a count= + 0
j:\>set now=0
j:\>set /a count+=1
j:\>if 1 LSS 5 goto loop
j:\>set now=1
j:\>set /a count+=1
j:\>if 2 LSS 5 goto loop
j:\>set now=2
j:\>set /a count+=1
j:\>if 3 LSS 5 goto loop
j:\>set now=3
j:\>set /a count+=1
j:\>if 4 LSS 5 goto loop
j:\>set now=4
j:\>set /a count+=1
j:\>if 5 LSS 5 goto loop


In both "logs" you can see that the "now" variable is assigned the current value of the "count" variable
and in the CMD window you can also see that the "IF" command shows the current value of the "count" variable as the left hand side of the evaluation
But it the TCC version the "IF" command line shows the "count" variable as un-expanded (%count%) on every iteration, so you can't see what value it had as each loop was processed.
Yes, the Watch list can show the value if I put a breakpoint at the "IF" line/
I have not yet explored the possibility of using conditional breakpoints (assuming Take Command supports them)

I am currently using the following work-around to achieve my required "log"
I add
echo count=%count% >nul&
at the front of a line that I want to see values at the time of line execution.
This provides the following in the TCC screen

set var=
set /a count= + 0
set now=0
set /a count+=1
echo count=1 >nul
if %count% LSS 3 goto loop
set now=1
set /a count+=1
echo count=2 >nul
if %count% LSS 3 goto loop
set now=2
set /a count+=1
echo count=3 >nul
if %count% LSS 3 goto loop


And to point out another difference between CMD and TCC, here is the CMD version of the same run.

j:\>set var=
j:\>set /a count= + 0
j:\>set now=0
j:\>set /a count+=1
j:\>echo count=1 1>nul & if 1 LSS 3 goto loop
j:\>set now=1
j:\>set /a count+=1
j:\>echo count=2 1>nul & if 2 LSS 3 goto loop
j:\>set now=2
j:\>set /a count+=1
j:\>echo count=3 1>nul & if 3 LSS 3 goto loop


Notice that TCC splits the line display when you have multiple commands on the same line !!!!
This can make it very hard to spot a failure - and is the subject of another BUG report
 
In both "logs" you can see that the "now" variable is assigned the current value of the "count" variable
and in the CMD window you can also see that the "IF" command shows the current value of the "count" variable as the left hand side of the evaluation
But it the TCC version the "IF" command line shows the "count" variable as un-expanded (%count%) on every iteration, so you can't see what value it had as each loop was processed.

This is WAD, and a critically important feature in TCC.

In CMD, the parser expands the entire command line at once, regardless of whether there are compound or conditional commands. TCC in contrast (by unanimous request, until now!) expands the individual commands when they're evaluated. This is essential in order to support internal variables, variable functions, and user defined functions, as their values can change depending on the actions of the previous command. (Since CMD only has a half-dozen internal variables and no functions, CMD-compatible batch files don't need to worry about this.)
 
Notice that TCC splits the line display when you have multiple commands on the same line !!!!
This can make it very hard to spot a failure - and is the subject of another BUG report

Also WAD. TCC treats multiple commands as multiple commands; CMD variously treats them as individual commands or a single command depending on the command you're running (i.e., IF - undocumented, and one of the more annoying CMD bugs).

If you want to emulate CMD closely (including the undocumented bugs), you can set some TCC options ("Duplicate CMD.EXE Bugs", and the CMDVariables option in TCMD.INI).

If you want (post-expanded) logging, see the TCC internal LOG command; it's much simpler than the output redirection you're doing.
 
@samintz, @Rex

What is a BDEBUGGER. Is this something different to the "Debugger" screen attached to the IDE ??

BDEBUGGER is the TCC command to invoke the batch debugger (i.e., the IDE but skipping all the intermediate steps to load the IDE and then load the batch file and then start debugging).

I am already using the Watch list, but it has 2 significant shortcomings :-
1st (and by design) it only shows the current value of the variable, not what it was the 5 times it was previously used.

WAD - I've never seen *any* debugger for any language that shows variable history. To do something like that would require saving the environment, all internal variables, all command variables, all variable functions, and all user-defined functions after running each command. This would put an enormous load on the system for a feature that nobody has ever requested.

The purpose of my request was to be able see what the value is at each step of the batch file when reviewing progress up to a break point.
When you are at the break point, you can only see the current values of the variables in the Watch list.

Are you single-stepping or running to the breakpoint? If you single-step, the watch window, environment window, and the modified window are all updated when each command is executed. If I understand correctly what you're after, you may want the Modified window (which shows the values that changed after each command).
 
@rconn Thanks for your replies, Rex.

This is WAD.
What is "WAD", and how do I use it when creating a Post ?
The "Post New Thread" only gives 3 options for the prefix - [Bug], [How To ?] and [Documentation]

This is essential in order to support internal variables,
The batch files I am working on are for server environments that do not have TCC (or TCMD).
I was only trying to get the debugger to show the same or at least sufficiently similar, to what is shown in a CMD run.
At this time, I am not knowingly using TCC except as part of the IDE for debugging batch files.
I can live with the added echo command I am currently using as a work-around so we can call this "How to ?" closed/completed

If you want to emulate CMD closely (including the undocumented bugs), you can set some TCC options ("Duplicate CMD.EXE Bugs", and the CMDVariables option in TCMD.INI).

I have tried to find the TCMD.INI file, but cannot find it in the 346,671 files in 58,769 folder on the PC I installed the demo on using Total Commander's File Search function looking for tc*.ini.
The TCC Help file says that it will be created if it doesn't exist, but the folders listed as possible locations are empty.
I have even looked in the \VirtualStore\ folder that Win7 uses to save files with permission conflicts - not there either.
Note :- I have not tried to run TCC directly. I am only using the IDE, and it seems to invoke TCC.exe as ther "Debugger" window
Should this be put into a separate Thread ?
If so, is it a BUG (.ini file not created), or a documentation error (TCC doesn't automatically create the ini OR something missing in the user instructions) or an operator error ( I am not using the IDE the correct way) ??

If you want (post-expanded) logging, see the TCC internal LOG command
How do I access this LOG command from the IDE ??

WAD - I've never seen *any* debugger for any language that shows variable history
I was only noting the the Watch window shows "Now" and did not mean to make it look like I wanted changes to the Watch window.
The history is there to read in the debugger window.
May be you haven't explored the facilities of the CMD window. I normally have it set to 200 characters wide with the screen buffer "height" set to 20,000 lines, so I can scroll back through previous debug runs, as well as having a long "monitor log" on the current debug run.

Are you single-stepping or running to the breakpoint?
I am using breakpoints set to trigger just before the loop should be reaching completion. Using single-step to go through some hundred lines or so for over a 1,000 loops would take several hours and wear out keyboard and/or mouse to get to the same point. Using breakpoints at every place I want to monitor the variable changes might halve the time, but I would still need to make a note of the variable's value at each check.
As I said earlier in this post, I can live with the added echo commands. They can all be removed with global replaces after debugging is finished.

Errol
 
_ININAME returns the fully qualified pathname of the INI file used by the current shell.

Example:

Code:
echo %_ininame

C:\Program Files\JPSoft\TCMD18_x64\TCMD.INI

Joe
 
@Joe Caverly Thanks Joe, but when I run the following :-

echo off
echo %_ininame
type "%_ininame"


I get the following :-
C:\ProgramData\JP Software\Take Command 21\TCMD.INI
TCC: (Sys_ J:\test.bat [2] The system cannot find the file specified.


Errol
 
@rconn Rex, I have identified that the ini file does get created IF I run the "Take Command v21" menu entry on the "TCMD21" menu.

So you will have to determine which one is the culprit :-
- running the IDE doesn't trigger creation of the ini file
- the doco about automatic creation is wrong
- the normal install is misleading - it creates a "Debugger" entry on the main Start Menu in Windows 7 and there is no info in the readme.txt file to say that TCC has to be run to initialise the ini file.

If you want to emulate CMD closely (including the undocumented bugs), you can set some TCC options ("Duplicate CMD.EXE Bugs", and the CMDVariables option in TCMD.INI).

Now that I have found how to get the ini file created, what is the syntax, and in what section of the ini file do these options go ?
 
@rconn Rex, I have identified that the ini file does get created IF I run the "Take Command v21" menu entry on the "TCMD21" menu.

So you will have to determine which one is the culprit :-
- running the IDE doesn't trigger creation of the ini file
- the doco about automatic creation is wrong
- the normal install is misleading - it creates a "Debugger" entry on the main Start Menu in Windows 7 and there is no info in the readme.txt file to say that TCC has to be run to initialise the ini file.

None of those are incorrect. TCMD.INI is created by running either TCMD or TCC. Running the IDE does not create or modify the TCMD.INI file, because it is only used by TCMD and TCC.

Now that I have found how to get the ini file created, what is the syntax, and in what section of the ini file do these options go ?

TCMD.INI is created when you run OPTION (in TCC) or "Configure Take Command" (in TCMD).
 
@rconn
The batch files I am working on are for server environments that do not have TCC (or TCMD).
I was only trying to get the debugger to show the same or at least sufficiently similar, to what is shown in a CMD run.
At this time, I am not knowingly using TCC except as part of the IDE for debugging batch files.
I can live with the added echo command I am currently using as a work-around so we can call this "How to ?" closed/completed

I have seen some CMD batch files that failed in TCC due to the use of undocumented CMD behavior (bugs), though I've never yet seen one that actually needed to be (or should have been) written that way.

The IDE / batch debugger is intended for debugging TCC scripts, and not to replicate every CMD bug. Even if you don't have TCC or TCMD on the servers, you can still write (vastly simpler and vastly more powerful) batch files using the TCC scripting language (a superset of CMD), and then deploy them using the free TCC-RT (TCC runtime).

How do I access this LOG command from the IDE ??

LOG is a TCC internal command; add it to the beginning of your batch file.

May be you haven't explored the facilities of the CMD window. I normally have it set to 200 characters wide with the screen buffer "height" set to 20,000 lines, so I can scroll back through previous debug runs, as well as having a long "monitor log" on the current debug run.

There isn't any "CMD window" - I presume you're referring to the Windows character mode console running a CMD session.

You apparently haven't explored the facilities of the TCMD tab windows, which have many thousands more features than the ancient & creaky Windows console.

I am using breakpoints set to trigger just before the loop should be reaching completion. Using single-step to go through some hundred lines or so for over a 1,000 loops would take several hours and wear out keyboard and/or mouse to get to the same point. Using breakpoints at every place I want to monitor the variable changes might halve the time, but I would still need to make a note of the variable's value at each check.
As I said earlier in this post, I can live with the added echo commands. They can all be removed with global replaces after debugging is finished.

Then use the conditional breakpoints in the IDE / debugger.
 
Modify or Display TCC Configuration using the OPTION command.
@Joe Caverly Thanks for the link to the info on TCC Initialization Files. It gave me most of what I was looking for.
Note :- The OPTION command does not give access to the Advanced Directives that I was trying to use.
It appears they need to be put into TCMD.INI manually with a text editor.

The IDE / batch debugger is intended for debugging TCC scripts
Unfortunately your home page does not clearly say this, and I have been evaluating the IDE for use in developing batch files for use in environments that do not have TCC.
Now that you have told me this, I will wait for your response to my request for info on the RT version before I do any more on this evaluation.

You apparently haven't explored the facilities of the TCMD tab window
Up until your mention of the free RT version, I had no intention of using TCC features in the development of batch files that will be run in a CMD environment.
Now that I do know, I will leave looking at the TCMD window until the IDE is de-bugged.

Then use the conditional breakpoints in the IDE / debugger.
@rconn Did you mis-read my post - I said I am using breakpoints set to trigger just before the loop should be reaching completion. This is using the
"Break >=" feature in the "Breakpoints" list.
I still haven't found any info on how to use the "Condition" feature.
It doesn't seem to use CMD syntax (%var% EQU 7), nor VB syntax (var = 7).
May be I will post a "How To ?" thread to find out how to use it if I continue the evaluation.

Errol
 
TCC-RT cannot be used interactively. It will execute scripts or commands named in its startup command. It must be present and executable on the machines where it will execute scripts. I suppose that means it must be installed there.

To attach a condition to a breakpoint, create the breakpoint, right-click on it and choose "Condition" from the context menu ... enter a conditional expression.
 
Even with more TCC-like syntax, "%zz EQ 2", I cannot get a conditional breakpoint to work.
 
@vefatica Thanks Vince, now I need to find out the installation process.
I have downloaded the RT file from the "Downloads" menu. I will set up a server VM to test it.

Even with more TCC-like syntax, "%zz EQ 2", I cannot get a conditional breakpoint to work.
@rconn So, Rex, what is the syntax for the "Condition" on a conditional breakpoint ?

Errol
 
Even with more TCC-like syntax, "%zz EQ 2", I cannot get a conditional breakpoint to work.
I was looking at it the wrong way, thinking that the breakpoint would be triggered if EITHER >= or condition were true. Rather, the breakpoint is triggered when BOTH are true. So, leaving "Break >= 0", a BP will trigger if and only if "Condition" is true. "Condition" has the normal TCC syntax for "conditional expressions" (see the help). It does seem to work. I've used such conditions as "%var == value", "1 == 1", "1 == 2", "defined varname", and "exist filename".
 

Similar threads

Back
Top