WAD Difference between TCC and CMD in handling multi-command lines

[Tech.batch]

Day 2 of the evaluation - still debugging the debugger - YAB !!!

Here is a sample batch file to demonstrate the very significant difference between TCC and CMD in handling multi-command lines

cls
set var=1&set chr=A
echo Testing& set var=2 & set chr=B & @echo Started %var% %chr%& if %var% GTR 1 echo Still in Test %var% %chr%
@echo test Finished %var% %chr%

When run in Take Command IDE, following is shown on the Debugger screen :-

set var=1
set chr=A
echo Testing
Testing
set var=2
set chr=B
Started 2 B
Still in Test 2 B
test Finished 2 B

And when run in a normal CMD window :-

j:\>set var=1 & set chr=A
j:\>echo Testing & set var=2 & set chr=B &
Testing
Started 1 A
test Finished 2 B

Note that the "Still in Test" echo ONLY happens in TCC !!!
This is because the CMD interpreter uses the variable values at the time before the line is executed, and the whole line is expanded, then executed. Effectively none of the changes to variables are visible until AFTER the line has been executed.
Whilst this functionality of CMD may be considered a "bug" and often causes many lost hours in debugging, I consider it to be a feature.
If the intention is to use the updated values, CMD now has the "delayed variable expansion" option that can be used to force a re-interpretation of a command in the multi-command line

TCC apears to be breaking the multi-command line into multiple single command lines and executing each separately, but with an interesting twist.
The "@" at the front of the "@echo Started %var% %chr%" command suppresses the echo of the command execution.
In CMD, this effects the rest of the multi-command line so display of the "IF command is also suppressed.
Did you spot the twist ?
Yes, even though TCC appears to be processing the multi-command line as single commands, the "@" suppressing the "echo" command has ALSO affected the "IF" command and it's display is suppressed too !!!

Enough for today.
Time to do some real work.

 

[rconn]

Day 2 of the evaluation - still debugging the debugger - YAB !!!

Note that the "Still in Test" echo ONLY happens in TCC !!!
This is because the CMD interpreter uses the variable values at the time before the line is executed, and the whole line is expanded, then executed. Effectively none of the changes to variables are visible until AFTER the line has been executed.
Whilst this functionality of CMD may be considered a "bug" and often causes many lost hours in debugging, I consider it to be a feature.
If the intention is to use the updated values, CMD now has the "delayed variable expansion" option that can be used to force a re-interpretation of a command in the multi-command line

TCC apears to be breaking the multi-command line into multiple single command lines and executing each separately, but with an interesting twist.

I made the decision (based on the input of 99.99% of the users) to NOT emulate this CMD bug, but to process the command line sensibly so that changing variables in one command would affect subsequent commands. (I originally did it the CMD way, and I would get dozens of "bug" reports a week about not evaluating variables correctly.)

To do it like CMD would mean breaking almost all of the internal variables and variable functions (and user-defined functions), and a few zillion existing TCC aliases and batch files. I don't think you'll get a lot of support for a unilateral change like that.

If you want, you can post a suggestion in the Suggestions Forum asking that TCC expand variables for compound & conditional commands before the line is parsed (i.e., without regard to the actual state of the system when each command is executed). This would provide your desired CMD compatibility, though it would eliminate most of the TCC variables/functions capability. I suspect if this CMD bug-behavior is critical to you, you will be better off running CMD directly.

Note that there is another TCC option (in TCMD.INI) that will run .BAT and .CMD files using CMD for 100% buggy-CMD-compatibility.

 

[Tech.batch]

@rconn Thanks for your reply Rex.

It may be that I am not understanding the primary purpose of Take Command.
I had interpreted the opening line on your web page :-
Take Command is a comprehensive interactive GUI and command line environment that makes using the Windows command prompt and creating batch files easy, faster and far more powerful
to mean that it is an IDE & Debugger, but the more I see of it, it appears to be a replacement for CMD.EXE that has it's own integrated IDE.
If it takes too many kludges and work-arounds to allow running a batch file the same as it would in CMD.EXE, then I can stop the evaluation right now.

Note that there is another TCC option (in TCMD.INI) that will run .BAT and .CMD files using CMD for 100% buggy-CMD-compatibility.

If this will let me use the IDE & Debugging facilities for a normal CMD environment, could please tell me what it is and where, in TCMD.ini it is intended to go.

Errol

 

[rconn]

Take Command has three components:

1) The Take Command tabbed console environment. This is intended to run *any* console app, including TCC, CMD, PowerShell, bash, etc.
2) The TCC Windows command interpreter. This is intended to replace CMD with a vastly more powerful command prompt.
3) The IDE / batch debugger. This is intended for debugging TCC scripts; it can also be used for debugging CMD scripts if you don't get carried away with the CMD undocumented features (i.e., bugs). What you've talked about so far has been using the CMD bugs for no clear reason other than cleverness, as you can accomplish the same thing with identical (and simpler, and easier to debug) syntax in CMD and TCC.

There is a fourth component "TCC-RT", which is a free runtime version of TCC that you can deploy to run scripts created with the full TCC + IDE.

The only way to create a 100% compatible CMD replacement is to eliminate every additional feature and produce a clone of CMD, with no additional commands, variables, or options for existing commands. (And it would have to be written for a specific version of Windows, because CMD isn't 100% compatible with itself in different versions.) TCC balances the desire for compatibility (99.9%) with CMD with the additional features that the TCC users have requested. Probably 90%+ of the TCC users don't even care about CMD compatibility -- but I try to keep it as close to a compatible superset of CMD as possible solely to make it easier for new users to acclimate. (And to run existing third-party batch files.)

 

[rconn]

@rconn If this will let me use the IDE & Debugging facilities for a normal CMD environment, could please tell me what it is and where, in TCMD.ini it is intended to go.

There is no way to run CMD in the IDE/debugger, as CMD lacks the debugging hooks that are necessary (and which are present in TCC).

The "CmdBatch=Yes" directive in the [4NT] section of TCMD.INI will tell TCC to run CMD whenever you try to execute .BAT or .CMD files.

 

[Tech.batch]

The IDE / batch debugger. This is intended for debugging TCC scripts;

This is at odds with the description on the JP Software home page where it states :-
makes using the Windows command prompt and creating batch files easy
In fact TCC and the IDE are a replacement for the Windows command prompt, NOT an aid to it.

There is a fourth component "TCC-RT", which is a free runtime version of TCC

@rconn How do I find out more about this free runtime version ?
Does it have command line parameters to be used when invoked ?
Can it be used as the default command processor ?
How is it restricted to a "runtime version" ?
Does it require special instalation on the client's server ?

The "CmdBatch=Yes" directive in the [4NT] section of TCMD.INI

Thanks Rex, the TCC online doco did not say where to put the directive, and of course it didn't work when placed in the [TakeCommand] section.
This DOES let me use CMD.EXE from the IDE in a very restricted format i.e. pressing "Run" starts the batch file in CMD, then waits until it finishes (returns to the DOS Prompt) before allowing edit access to the source batch file.
This could still be useful to me except for the bugs I have found in the IDE - see my next "BUG" thread https://jpsoft.com/forums/threads/problem-with-use-of-batch-parameters-in-the-ide.8247/

Errol

 

[rconn]

This is at odds with the description on the JP Software home page where it states :-
makes using the Windows command prompt and creating batch files easy
In fact TCC and the IDE are a replacement for the Windows command prompt, NOT an aid to it.

No - Take Command is an enhancement (and a wrapper) for the Windows console. TCC is a replacement for the default Windows command processor CMD (not the same as the Windows command prompt). IDE is a GUI add-on for TCC, and has nothing to do with the Windows command prompt.

@rconn How do I find out more about this free runtime version ?
Does it have command line parameters to be used when invoked ?
Can it be used as the default command processor ?
How is it restricted to a "runtime version" ?
Does it require special instalation on the client's server ?
[/quote]

You can download, install and try TCC-RT and get all of the answers.

TCC-RT is only for running batch files; it is not a stand-alone (interactive) command processors. You can pass whatever command line arguments you want to the batch file. You obviously need to install TCC-RT on the target machine, but there aren't any license restrictions on doing that.
[/QUOTE]