Restore tcc/le detection logic back from v1.3.20 (regression)

[daxgames]

@DRSDavidSoft Do you know why the below was removed in v1.3.21:

This was to avoid compatibility issues with the tcc shell some users were using.

I think it should be added back unless you found those issues have been resolved.

[DRSDavidSoft]

@daxgames Good catch! Apologizes for the late response, this is the commit in question:
e3d9f81

After a bit of investigation I think the lack of elaboration is a oversight on my part.

The removed code in question has two roles, disabling clink on tcc/le hosts, and disabling Cmder aliases.

Regarding the first role, I recall that due to Clink's own internal detection (code block at the end), I deemed that it would be unnecessary for Cmder to also do it using batch script.

There is a related Clink issue about tcc/le here: chrisant996/clink#177

So I think it would be best to ask @chrisant996's opinion, do we need to detect and disable injecting Clink from the Cmder's batch script side, or, is it acceptable to run Clink in a tcc/le shell and expect no issues (including any produced warnings)?

I'm fine with either way -- if we need to do it from the batch scripts, then I apologize for the removal without explanation and need to restore it as it is indeed a regression.

Otherwise, it would be fine to execute Clink and expect it to handle the ComSpec host.

Note

Clink has explicit checks for "tcc.exe", but not "tccle.exe", which could possibly be an inconsistency.

@daxgames The only other role is to disable Cmder aliases in TCC/LE hosts. Unfortunately I don't seem to recall the results of my experiments when I ran Cmder + TCC, I assume the were no problems at the time, and that is the reason for the guard removal.

I need to install TCC and Cmder in a sandbox environment to do some tests to make sure about it.

Here's the history and Copilot's recommendation, for archival sake (click to expand)

---

Why tcc and tccle detection was removed — commit history

The removal happened in two stages, each with a distinct reason:

---

Stage 1 — d1b1012 (Sep 9, 2022): Detection method replaced, not removed

Commit: d1b1012 — "minimal comspec detection (fixes #2744)" by David Refoua (@DRSDavidSoft)

What changed: The original detection used find /i "\tcc.exe" and find /i "\tccle" piped from %COMSPEC%:

echo %comspec% | %WINDIR%\System32\find /i "\cmd.exe" > nul && set "CMDER_SHELL=cmd"
echo %comspec% | %WINDIR%\System32\find /i "\tcc.exe" > nul && set "CMDER_SHELL=tcc"
echo %comspec% | %WINDIR%\System32\find /i "\tccle"   > nul && set "CMDER_SHELL=tccle"

This was replaced with a simpler generic approach:

call :detect_comspec %ComSpec%
...
:detect_comspec
    set CMDER_SHELL=%~n1   :: just takes the filename without extension

Why: Issue #2744 reported that calling C:\WINDOWS\System32\find /i "\cmd.exe" at startup was being blocked by Avecto (Privilege Guard) application whitelisting software — a Windows security product that flagged the backslash-prefixed search string as suspicious. Switching to %~n1 (batch filename modifier that extracts just the name without extension from %ComSpec%) completely eliminated the find.exe call. The tcc/tccle special-casing for CMDER_CLINK=0 and CMDER_ALIASES=0 was still preserved at this point.

---

Stage 2 — e3d9f81 (Nov 6, 2022): The remaining tcc/tccle guards removed entirely

Commit: e3d9f81 — "add prompt for vanilla cmd.exe when clink not present" by David Refoua (@DRSDavidSoft)

What changed: The four remaining lines that disabled Clink and aliases for tcc/tccle were deleted:

-        if "%CMDER_SHELL%" equ "tcc"   set CMDER_CLINK=0
-        if "%CMDER_SHELL%" equ "tccle" set CMDER_CLINK=0
...
-        if "%CMDER_SHELL%" equ "tcc"   set CMDER_ALIASES=0
-        if "%CMDER_SHELL%" equ "tccle" set CMDER_ALIASES=0

Why: The commit's stated purpose was adding a prompt for vanilla cmd.exe when Clink is not present — a broader refactor of init.bat and related library files. The tcc/tccle lines appear to have been silently dropped as part of the cleanup, with no explicit mention in the commit message. This is consistent with the v1.3.21 changelog entry: "Remove handling of clink and tcc incompatibility."

The original reason those guards existed was that Clink and aliases were incompatible with TCC/LE (Take Command Console / TCC LE — JP Software's alternative shells). Clink is a readline-like input enhancer that hooks into cmd.exe internals, and it simply doesn't work with third-party replacements for cmd.exe. When the whole detection approach was being simplified and refactored, the TCC-specific workaround was dropped — likely because TCC/LE had itself been discontinued (JP Software ended TCC LE as a free product around 2016, and the commercial TCC has a small user base).

---

Summary timeline:

Date	Commit	Author	Change
Sep 2, 2018	823e6fe	Dax T. Games	Added tcc.exe/tccle detection + disable-Clink/aliases guards
Sep 9, 2022	d1b1012	David Refoua	Replaced find.exe-based detection with %~n1 (fixes #2744 / Avecto blocking)
Nov 6, 2022	e3d9f81	David Refoua	Removed the remaining tcc/tccle guards entirely (cleanup/refactor)

---

chrisant996/clink handles TCC natively — Cmder does NOT need to add guards back

The current Clink (chrisant996's fork) has explicit, deliberate TCC/4NT awareness built into its C++ injection code in two places:

1. clink/app/src/loader/inject.cpp — Injection-time host check

// Check for supported host (keep in sync with initialise_clink in dll.cpp).
const bool is_tcc = !stricmp(host_name, "tcc.exe");
const bool is_4nt = !stricmp(host_name, "4nt.exe");
if (is_tcc || is_4nt)
{
    // Take Command (and 4NT) from JPSoft are recognized during
    // autorun as benignly invalid hosts.  They may invoke the
    // AutoRun regkey contents and try to inject Clink, which is
    // just a side effect of their design.  Since the scenario
    // is well understood, it's reasonable to be silent about it
    // during autorun.
    if (is_autorun)
        return {-1, nullptr};  // Silent rejection
    LOG("Host '%s' is not supported; Clink is not compatible with the JPSoft command shells.", host_name);
    return {};  // Hard rejection
}

When Clink is triggered via autorun (as happens in Cmder), it silently returns -1 for TCC/4NT — no error, no message, no crash. When injected manually it logs the incompatibility and exits cleanly.

2. clink/app/src/loader/inject.cpp — find_inject_target() also skips TCC

static DWORD find_inject_target()
{
    ...
    if (_stricmp(name, "cmd.exe") == 0)
        return pid;
    if (_stricmp(name, "tcc.exe") == 0 || _stricmp(name, "4nt.exe"))
        return pid;
    ...
}

3. clink/app/src/dll/dll.cpp — Post-injection DLL host check

The initialise_clink function in the DLL (which runs after injection) also only supports cmd.exe in its hosts[] table and bails out with "Unknown host" for anything else — so even if injection somehow proceeded, Clink would safely do nothing.

---

Conclusion

Cmder does NOT need to add the guards back. The old Cmder guards (if CMDER_SHELL == tcc set CMDER_CLINK=0) were a workaround for the old mridgers/clink which had no TCC awareness. chrisant996/clink has handled this properly in its own C++ code since at least v1.x — it explicitly recognizes tcc.exe and 4nt.exe, and when invoked via autorun silently does nothing, preventing any crash or error dialog. The problem that originally motivated the Cmder guards no longer exists.

[chrisant996]

do we need to detect and disable injecting Clink from the Cmder's batch script side, or, is it acceptable to run Clink in a tcc/le shell and expect no issues (including any produced warnings)?

TL;DR

• The only thing that happens is an error message; no further issues beyond that.
• If you want to avoid the error message, then avoid injecting.

Details

• If an attempt is made to inject Clink into a JP Soft shell, then the injection will report an error message and do nothing further.
• If Clink is configured for AutoRun and a JP Soft shell is launched, then the injection attempt will suppress the error message.
• Except that due to a typo, the suppression only worked for tcc.exe (not for 4nt.exe or tccle.exe).
• For Clink v1.9.19 (not published yet), I've made some fixes/improvements to the JP Soft shell detection logic to fix the quirk mentioned above, add detection for tccle.exe, add a friendlier error message when a JP Soft shell is detected, and etc.

[DRSDavidSoft]

@chrisant996 Excellent, thank you ❤️

@daxgames Based on this I believe I need to restore the lost logic. Thank you for bringing this regression to my attention!