What are the TCC settings that will allow maximum cmd.exe compatibility?

[bigloudjeff]

I am trying to use TCC with a legacy build system that is loosely based on the windows driver sdk. Everything we do inside our build environment is done through batch files. Even the simplest source code control commands are wrapped with batch files. Some of the batch files are extremely long and complicated. The batch file run at the start to initialize the environment is several hundred lines long.

These batch files all run fine under cmd.exe on all of the still supported versions of windows. But when I try to run them in TCC I get several errors. Most of them are about unbalanced parentheses and other mismatch characters. I have played a little with the SETDO command and the CMDvariables setting. But I have had no luck in getting any of our batch files / cmds to run successfully under tcc.

Is there a guide or tutorial on setting up TCC for maximum cmd.exe compatibility?

Thanks,

Jeff

 

[kramed]

I am wondering the same thing. I am testing TCC and TCC/LE and some of the scripts I use the most are not working correctly.

https://github.com/davidmarble/virtualenvwrapper-win

I wonder if the problem is in the scripts or TCC itself.

 

[rconn]

Assuming you're running the current version (13.06), there are only a handful you need to worry about.

Enable these three options:
OPTION / Startup / Duplicate CMD.EXE bugs (This is the default, and tells TCC to duplicate two bugs in CMD's IF command parsing.)
OPTION / Startup / CMD.EXE delayed expansion (If you have this startup option set for your CMD.)
OPTION / Startup / Search for SFNs (Not recommended unless you want some potentially unpleasant results when you're copying, moving, or deleting files, but it *is* how CMD does it.)

and set "CMDVariables=YES" in your .INI file. (This means you won't be able to run any batch files written for TCC/LE, which only requires a single leading % for variables. But if you want near-100% compatibility with CMD ...)

If you want to get that last fraction of CMD compatibility and don't mind removing most of the TCC/LE features, you could also disable all of the TCC/LE commands that aren't in CMD. (Otherwise, TCC/LE might find an internal command name match while CMD would find an external app.) And maybe "SETDOS /X279" to disable nested aliases, quoting, and include lists. Disable global aliases and history. Turn off ANSI support (OPTION / Windows / Colors). Turn off pseudovariable expansion (OPTION / Advanced / Special Characters). Disable deleting to the recycle bin (OPTION / Startup).

If you want CMD-style command line editing (i.e., practically none), you can remove most of the TCC/LE command line editing features (OPTION / Command Line).

 

[Stefano Piccardi]

Seriously, your comprehensive and concise answer should be pinned in this forum.

 

[dcantor]

Seriously, your comprehensive and concise answer should be pinned in this forum.

... and put into the help file.

 

[Charles Dye]

... and put into the help file.

With a warning, perhaps, that CMDVariables=YES is essentially a software lobotomy.

 

[rhubarb]

Is there anyway you can disable an internal command such that it falls back to the CMD command? I tried this with setdos /I-pushd and it simply fails to recognize pushd after that

 

[Steve Fabian]

WAD. No, CMD compatibility is NOT a fall-back option. But if CMD uses an external program to perform one of "its own" commands (if it is an external, it is not really CMD's command!), disabling the corresponding TCC command with SETDOS should execute the same external (assuming your PATH is appropriate).

 

[rhubarb]

Thanks again Steve.
It's a shame I have to say. I've wasted too much time in the past 2 days trying to work around the differences between the CMD and TCC/LE versions of PUSHD/DIRS. I can even make do with DIRS instead of the CMD behaviour of PUSHD if only it would list dirs in the same order as CMD PUSHD (no-args).

It's frustrating that TCC would have a different implementation and no way to behave compatibly.

Then again, I suspect TCC (which I've been using since it was 4DOS) had PUSHD long before CMD, so it's hardly responsible. Still it would be great to have an update where as a general rule all TCC commands for which there are _builtin_ CMD commands had a compatibility mode argument that could make them work like the _current_ version of CMD (and, yeah I know that's a moving target, so its not easy). The external windows commands, like you say, are not such a big deal, because you can use setdos to disable the TCC version.

 

[AnrDaemon]

If you want CMD.EXE compatibility, why do you use a different software to begin with?…
CMD.EXE is rich in its own right. If you know how to work around its deficiency, of course.
For last four years I was writing new (CMD) and rewriting old (4NT converting to CMD) scripts and I came across major incompatibity of TCC in the parameter parsing.
If you write a script with alot of parameter expansion and subroutine calls, be prepared that it may(or rather will) not work in CMD.

 

[smf]

Assuming you're running the current version (13.06), there are only a handful you need to worry about.

You should also add enable UNIX/Linux-style paths to the list of cmd compatibility settings.

If you want CMD.EXE compatibility, why do you use a different software to begin with?…

I have used TCCLE for years, I had a license to 4NT before that, 4DOS before that and NDOS before that. I work on projects that are cross platform, but everyone else using windows either uses cmd or cmder. I want CMD compatibility plus all the extras that I've gotten used to without switching between different shells. I can live without CMD bugs that are not replicated, as long as they aren't the only way to achieve functionality that others may rely on.

 

[dcantor]

This topic is marked as sticky. Can someone please unstick it?