Debug feature bug?

[sambul35]

Hi,

I'm new to TakeCommand, just trying... It looks like it can't debug more complex batches, or Am I doing something wrong? Like this section:

@echo off
SETLOCAL ENABLEDELAYEDEXPANSION ENABLEEXTENSIONS
SET "diskpart=echo exit|%ComSpec% /k prompt %%dsc%%$_|diskpart"
SET dsc=select$Sdisk$S%dsk%$_detail$Sdisk & SET dsk=7
%diskpart%|find /c "Volume"

The above small code section allows to count number of volumes on a mounted selected virtual or physical disk. It was simplified to check the TakeCommand Debug feature, so pls don't suggest how to change it - this is not the purpose of this thread. It works OK in Win7 32/64 Console. But in Debug it gives error, when attempting to debug it as is and with some variations.

Can I or the program author fix it? How limited is Debug feature?

 

[Charles Dye]

That's, um, peculiar. But when I run it in BDEBUGGER, I don't see any error messages; it just displays the number 0. What message do you get?

 

[rconn]

I'm not sure what you're trying to do, or what you mean by "TakeCommand Debug feature" -- are you referring to the batch debugger?

A quick look at your batch file shows one probable place for an error to occur -- if you install Take Command in the default directory (\Program Files\JPSoft\) you'll get an error in line 5 because you didn't quote %COMSPEC% (which has embedded whitespace) in line 3. (CMD.EXE is normally in c:\windows\system32, so it has no embedded whitespace and doesn't need quoting.)

You could also choose to install Take Command somewhere other than "c:\program files\jpsoft\...", so you wouldn't need to quote it if you select a suitable target directory name.

 

[sambul35]

Thanks rconn,

Its part of a batch section to find out in Win7 what volumes of an attached VHD virtual drive remain unmounted. May be you can suggest another approach to find that out automatically via batch?

I changed it a bit, now it works in your Batch Debugger:

@echo off
SETLOCAL ENABLEDELAYEDEXPANSION ENABLEEXTENSIONS
SET "diskpart=echo exit|"%ComSpec%" /k prompt %%dsc%%$_|diskpart" & SET dsk=7
SET dsc=select$Sdisk$S%dsk%$_detail$Sdisk
%diskpart%|find /c "Volume"
rem-------------------------------------
set vol=15

In what directory should I install it to avoid such surprises? ;) Also, I expected the debugger to give some more hints compare to Console about the code failure reason and possibly suggest some changes, but it doesn't. What are the advantages of using it in this case - just step execution?

Another thing, can it Evaluate Expression like:

set /a "vlm=%diskpart%|find /c "Volume"-%vol%+2"

in context of the open batch? This expression or its variations don't seem to work in Console, and I'm not sure, whether "Evaluate Expression" in your program can help debugging it?

 

[rconn]

You can install Take Command anywhere you want, provided you're aware of the potential problems if you reference %COMSPEC and assume it will always be in an SFN directory. If you don't want to have to think about that, you could install Take Command someplace like "d:\tcmd".

The debugger did the best it could given the invalid filename you told it to execute; it flagged the error and stopped. IMO it's beyond the scope of a debugger to try to guess what you really meant and blindly substitute its guesses and continue.

When you say "Console" are you referring to a CMD.EXE console window?

Take Command can evaluate arithmetic expressions with SET /A or the @EVAL internal function; but in your example not everything in that expression is numeric. The pipe won't work because it's inside a double quoted string, so you're trying to do a numeric evaluation of a string combined with a constant combined with the variable values (which could be anything).

 

[sambul35]

Thanks rconn,

Yes, I mean Win7 Command Prompt. But it doesn't work without quotes either. Anything else you can suggest to make it work? Variable was set to 15 in the above post example.

 

[rconn]

You can't assign the output of an external app as if it were an environment variable. You need another step -- see the @EXECSTR variable function description in the help.

 

[sambul35]

Sorry to point your attention that %diskpart% here is environment variable defined above, it just happen to have the same name with Diskpart command. But it works OK this way in FOR and SET and other enclosed commands. The only case I found it doesn't work is with SET /a , so I'm wandering how to change its systax. I also read that SET /a is very limited and buggy.

 

[Charles Dye]

I think you'll find SET /A less limited in TCC than in CMD. TCC's version supports floating point and very large numbers, and doesn't assume that numbers beginning with 0 are octal.... As for bugs, if you can find one, Rex'll fix it!

 

[rconn]

Sorry to point your attention that %diskpart% here is environment variable defined above, it just happen to have the same name with Diskpart command..

I wasn't referring to %diskpart%, I was talking about the pipe and FIND command you're trying to embed in a string.

SET /A is limited (but not buggy in TCC). But I think you'll find that the @EVAL variable function is neither limited nor buggy.

 

[sambul35]

Thanks for the suggestions! But if I use TCC functions that aren't available in standard CommandLine, the program won't run on a typical user's PC - right? I see the error in my above expression logic now. Why then this expression works well:

set "str=%diskpart% | findstr /c:Volume | findstr /v "###""

Responding to Charles's TCC bug report request above, the program crashed and exited 3 times yesterday when trying to debug the Set /a expression with syntax variations, and 4 times posted "Can't write ABC.tmp file to disk". Are these things BUGs or features?

 

[rconn]

Sorry; you hadn't mentioned previously that you want to run the batch files under CMD.

*What* program crashed -- TCC, CMD, FINDSTR, or something else? (TCC would not display that "Can't write ABC.tmp file to disk" error message.)

If TCC crashes, it will create a .GPF file, in the same directory as the TCMD.INI, which varies by the Windows version. You can find it by running the OPTION command, which will display the TCMD.INI directory in the caption bar. If you have a reproducible failcase where TCC is crashing, please post the command line and the TCC.GPF file here.

 

[sambul35]

I do have such TCMD.gpf file, and I think it crashed several times, so the file was probably overwritten a few times, if they aren't numbered. Don't remember the exact command, but it was around the above SET /a function. Will do next time.

 

[rconn]

If you still have a TCMD.GPF file, please post it here.

 

[sambul35]

Sorry deleted. May I suggest you to number TCMD.gpf files... Because users wouldn't know they exist until ask here or read the Manual - seldom happen.

 

[rconn]

Numbering them wouldn't be useful, as there wouldn't be any way to tie them to a specific sequence of commands that caused the crash. The register info by itself is rarely useful.

BTW -- why did you delete it?

 

[sambul35]

The register info by itself is rarely useful.

 

[rconn]

99% of the time the crash is in a Windows API or the C++ RTL. The call stack can only be traced back so far (sometimes not at all, particularly if the crash was due to a stack failure), so it's essential to have a reproducible failcase in order to determine exactly *how* the program arrived at that state.