Cmder's Shell Terminal Integration in Nested CMD.EXE doesn't seem to work properly

[nguyenduy4321]

I followed the Terminals Integration instructions for CMD.EXE from cmder's wiki, including adding AutoRun. All should be fine if just run a cmd in each window separately.

We will have a problem running nested cmds. I understand the command @if "%cmder_init%" == "1" (goto :eof) else (set cmder_init=1) to prevent cmder from falling into an infinite loop and so it only runs exactly once even if called many times cmd nested in a window.

Do we have a way to solve it? I have tried modifying cmder_shell.bat as follows:

@if "%cmder_init%" == "1" (%CMDER_ROOT%\vendor\clink\clink.bat inject -q --profile "%CMDER_ROOT%\config" --scripts "%CMDER_ROOT%\vendor" && goto :eof) else (set cmder_init=1)
@pushd %CMDER_ROOT%
@call "%CMDER_ROOT%\vendor\init.bat" /f
@popd

Sorry for your eyes (because of my english), check my above script, if it's ok let me know.

[daxgames]

@nguyenduy4321 I am sorry I do not understand the issue.

[nguyenduy4321]

@nguyenduy4321 I am sorry I do not understand the issue.

Follow me:

1. Integrate cmder into cmd as the above guide and set AutoRun
2. Open cmd (cmd1), type cmd (cmd2) in cmd1
3. You see? cmd2 not be integrated cmder

[daxgames]

I see the issue now.

Your modification to the script seems to work except there is no need for the && goto :eof since you are not using call to run clink.bat. It is more readable as follows:

@echo off

if "%cmder_init%" == "1" (
  %CMDER_ROOT%\vendor\clink\clink.bat inject -q --profile "%CMDER_ROOT%\config" --scripts "%CMDER_ROOT%\vendor"
) else (
  set cmder_init=1
)

pushd %CMDER_ROOT%
call "%CMDER_ROOT%\vendor\init.bat" /f
popd

What is your question?

[nguyenduy4321]

Yeah, I mean we should update the guide for integrating cmder into CMD.EXE.

You have also seen the script we just discussed that helps cmder work with nested cmds

What do you think about this update? I believe many cmder users with CMD.EXE will need this update.

[chrisant996]

Just a friendly note:

Setting up AutoRun like that will slow down every CMD invocation (even the many background ones that don't show any window), and can potentially interfere with OS or app internal invocations of CMD that aren't expecting Cmder to do so much work. The script could also potentially cause things like installing OS updates to malfunction.

Something to keep it in mind in case you ever notice strange glitches in the future (or various operations being slower than normal) -- removing the script from AutoRun can be a good troubleshooting step whenever strange things are afoot on the computer.

Good luck!

[daxgames]

@nguyenduy4321 your update makes it work but I would not advise setting autorun for the very reasons @chrisant996 raised. I honestly considered removing it from the wiki.

Cmder users typically use an alternate terminal like conemu or windows terminal and leave vanilla cmd.exe alone.

[nguyenduy4321]

I feel sorry for cmd.exe to hear about your decision. I really like the simplicity of cmd.exe so I don't need windows terminal or conemu.

@chrisant996, I posted an issue for your clink a few days ago, that post also discussed nested cmd :)). if you say clink can potentially harm the OS?

[chrisant996]

I feel sorry for cmd.exe to hear about your decision. I really like the simplicity of cmd.exe so I don't need windows terminal or conemu.

@chrisant996, I posted an issue for your clink a few days ago, that post also discussed nested cmd :)). if you say clink can potentially harm the OS?

@nguyenduy4321 It sounds like you may be missing some information.

1. Maybe you are not aware of how often cmd.exe gets launched silently and automatically, hidden from view, as a non-interactive process, by internal and background processing of many programs. Many ways for scripts and programs to invoke other scripts or programs actually also invoke an extra cmd.exe instance as well.
2. Cmder's init.bat script is intended to do somewhat expensive things to set up an interactive command shell environment.
3. Cmd.exe runs the AutoRun regkey entries every time any cmd.exe is launched -- even for the many non-interactive, silent, hidden, background, internal invocations of command shells. Cmder's init.bat script can't be guaranteed to be reliable for all such operations.
4. The clink script is much simpler, does much less work, and Clink itself detects non-interactive command shell invocations and short-circuits to not actually inject Clink.
5. But no, I do not recommend setting up Clink for autorun, because even though it detects non-interactive command shell invocations, it still unavoidably adds a delay to every single cmd.exe invocation. I have not deleted that feature from Clink, because it already existed and people were already using it, and I take backwards compatibility very seriously. I myself do not use autorun; it is very simple to set up scripts, links, tasks, etc that invoke Clink when and where I want it.

By definition, anything that's put in AutoRun has the potential ability to harm the OS, as well as other apps. For example, did you know it's easy to accidentally send AutoRun into an infinite recursive loop that consumes all system resources by creating hundreds of new processes per second? If anything inside AutoRun launches another program, then it's likely going to do so by also silently launching a hidden cmd.exe instance ... which will run AutoRun, which triggers infinite recursion.

AutoRun is inherently risky to use. Good luck! 🙃

[chrisant996]

Here's one example of how AutoRun can break installing an update for something (app, OS, whatever):

Updates often involve running scripts. Suppose one of the scripts uses a variable name that's the same as a variable name used in a Cmder or Clink init script. Adding the extra scripts into the AutoRun regkey could interfere with the updater's script, causing it to malfunction in unpredictable ways.

There are many other possible ways as well; that was just one example.

Such problems are relatively unlikely to occur. Usually you will just notice things launch slower because AutoRun has extra work to do. But they definitely can occur. I've seen reports from some users where those types of interference issues are exctly what happened.

I don't mean to cause alarm. But just be aware that there are tradeoffs to consider when inserting extra work into AutoRun. If something weird happens on the system, remember that one of the troubleshooting steps should be to clear the AutoRun regkey.

[nguyenduy4321]

I seem to be a bit stubborn. Guess I should change to windows terminal

Well, I just had a problem with AutoRun, I stuffed a bunch of scripts into it so Qt couldn't run g++

Okay, removing AutoRun was a worthwhile decision.

[DRSDavidSoft]

@nguyenduy4321 If you're on Windows 11, you can set Microsoft Terminal as the default Terminal app on windows, so even if you type cmd.exe in the run menu, the new terminal app will open instead:
https://devblogs.microsoft.com/commandline/windows-terminal-as-your-default-command-line-experience/

Then, together with the Default profile option set to Cmder, you can get the behavior you're looking for in a more modern and safe way. This is what I use BTW, which is better than using AutoRun for every instance of cmd.exe that runs.

That's because cmd,exe is actually the COMSPEC, the actual terminal window that you see is conhost.exe. Preferably, we want the Cmder AutoRun to be ran on the terminal window, not on the comspec.

The only downside with this method instead of using AutoRun is that other apps (which include an embedded terminal) won't run the clink shell, so in those apps (an IDE for example) you have to type cmder_shell (or cs, if you prefer) in the start of the terminal to get the clink shell. Additionally, if you SSH into your machine, you have to do the same without AutoRun.

More info: https://superuser.com/questions/678650/what-does-comspec-mean