Debugging

[lazna]

What about to add some command to enable easily script debugging? Thinking about something like this:

• take script line
• execute command
• display used variables
• (optionaly) execute pause command

[adoxa]

* take script line

If that's what I think you mean, it's already done.

c:\Projects\enhancedbatch>type error.bat
@echo off
rundll32.exe %~dp0enhancedbatch_%processor_architecture%.dll,load
set /a

c:\Projects\enhancedbatch>error.bat
error.bat:3: The syntax of the command is incorrect.

That's the default; it can also display the full path or be turned off.

* execute command

Not sure what you mean.

* display used variables

Do you mean like set, but only for variables used up to this point? Does "used" mean set, or accessed as well? Is the intention to include the line where it was set/accessed? Not sure, that seems a fair bit of work for little result.

* (optionaly) execute pause command

Do you mean between each command?

[lazna]

Its just my guess. For example this loop

for /f %a in ('%path_to_exe% -a %par1% -b %par2% 2^> %path_to_lof_file% ^| %another.exe% -f %paht_to_out_file% ^| tee %filename%') do something

failed for some reason. Then I had to copy whole command, strip carrets, and put

echo _string_

before loop to fing what is wrong. Thinking about some option to print string with evaluated variables.. Maybe some king of built-in tee function. Only fuzzy ideas, I have no any solution..

[adoxa]

echo on usually works for me. Sounds like you want that with an option to keep the variables, e.g. -a %par1%=arg1 -b %par2%=arg2. Tricky, but doable, I think. Possibly expensive, so it'd have to be explicitly enabled.

[DaveBenham]

I don't think adding additional debug functionality is worth it. Printing the script and line number with the error message is a big deal. Knowing the failing line number is often all that is needed to figure out the problem. If more info is needed, then it should be relatively easy to set ECHO ON before, and/or add diagnostic ECHO statements before and/or after the offending line to figure out the problem.

Perhaps this issue should be closed, unless you think you might want to tackle some form of variable dumping in the future.

[adoxa]

I think keeping variable names within the echoed statement could be useful, but too complicated. A variable (environment/heap, not FOR or arg) log shouldn't be that hard, though, something like:

:: have EB remember the file and line number of each variable access
set @debugvars=on
...
:: display the information and reset
call @dumpvars
...
call @dumpvars
set @debugvars=off

[DaveBenham]

I meant that the user could be responsible for adding diagnostic ECHO statements to the script - old school debugging.

But if you want to implement @dumpvars, then go for it!

However, depending on the number of variables involved with the script, that may be a lot of info to wade through. Also, FOR and arg values are just as likely to be important.

I most likely would still rely on adding my own ECHO statements as needed if I need help debugging a script.

[adoxa]

No, I'm not sure it's worthwhile. Another approach could be to add a modifier to include the variable name in the expansion, thus echo var=%var% becomes echo %var;dump% (or something). It's not really any better, but would save doubling up long variable names. Hm, maybe a modifier that echoes directly (using another variable to control where).

:: current - add an echo statement to see what the variable is
echo var=%var%
command %var%
:: enhanced - add a modifier, that outputs like above, according to @batchfile
command %var;debug%

[carlos-montiers]

I think that is not needed to add more features to help the debugging