1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

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

Discussion in 'TCC/LE Support' started by bigloudjeff, Jan 28, 2013.

  1. bigloudjeff

    Joined:
    Jan 14, 2011
    Messages:
    1
    Likes Received:
    0
    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
     
  2. kramed

    Joined:
    Mar 21, 2013
    Messages:
    1
    Likes Received:
    0
  3. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    10,091
    Likes Received:
    85
    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).
     
  4. Stefano Piccardi

    Joined:
    May 31, 2008
    Messages:
    376
    Likes Received:
    2
    Seriously, your comprehensive and concise answer should be pinned in this forum.
     
  5. dcantor

    Joined:
    May 29, 2008
    Messages:
    515
    Likes Received:
    3
    ... and put into the help file.
     
    ed neff likes this.
  6. Charles Dye

    Charles Dye Super Moderator
    Staff Member

    Joined:
    May 20, 2008
    Messages:
    3,374
    Likes Received:
    40
    With a warning, perhaps, that CMDVariables=YES is essentially a software lobotomy.
     
  7. rhubarb

    Joined:
    Mar 26, 2013
    Messages:
    13
    Likes Received:
    0
    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
     
  8. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    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).
     
  9. rhubarb

    Joined:
    Mar 26, 2013
    Messages:
    13
    Likes Received:
    0
    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.
     
  10. AnrDaemon

    Joined:
    Aug 23, 2010
    Messages:
    83
    Likes Received:
    1
    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.
     
  11. smf

    smf

    Joined:
    Aug 3, 2015
    Messages:
    10
    Likes Received:
    0
    You should also add enable UNIX/Linux-style paths to the list of cmd compatibility settings.

    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.
     

Share This Page