CMD doesn't restore title after last statement in a batch file

[randomascii]

Environment

Windows build number: Microsoft Windows [Version 10.0.18362.836]
Windows Terminal version (if applicable): 1.0.1401.0

Steps to reproduce

Create these two batch files and then run b1.bat:

b1.bat: echo In b1 if 1 == 1 ( b2.bat )

b2.bat: echo In b2

Expected behavior

After the batch files stop running I expect the title of the running terminal, as shown in its tab, to return to its previous value, which defaults to "cmd".

Actual behavior

The title of the running terminal, as shown in its tab, is changed to b1.

The consequence of this is that if I run a long-running batch file and then go to another tab I cannot reliably use the title of the first tab to tell when the task has completed. This can be worked around using call followed by exit /b, but such workarounds should not be needed.

Here is an example of a workaround I added to Chrome's depot_tools:

https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/2225340

[jdebp]

This is a cmd thing, not a Terminal thing. You'll find that the if statement is important. Without it, cmd happily changes titles. And the failure to change title happens even if Windows Terminal is not in the mix, on the vanilla console server.

[jdebp]

Conversely, running the scripts with Windows Terminal, but under Take Command (after configuring Windows Terminal with tcc.exe), also does not reproduce the problem.

[randomascii]

Yes, I know that the if statement is important. I created a minimal repro, which is why the if statement is there.

I should have mentioned that it also reproes in cmd.exe. I mentioned that on twitter and was advised that it was still worth filing an issue here. Here is the tweet thread, FWIW:

https://twitter.com/richturn_ms/status/1267905670629609472

[DHowett]

I think we have one on our internal tracker (ninja edit: MSFT:15825653 )for this, so I'm gonna tag this up as Tracking-External. It's not likely to be fixed, since the bar for CMD changes is pretty high and there is a workaround. Sorry ☹️

(Every time we change CMD, we get a regression report ~8 months later when it finally makes it into the hands of our partners. I've become hesitant to commit to fixes that don't fix stop-the-world bugs for our favorite old shell.)

[zadjii-msft]

To the surprise of no one, this didn't meet the cmd.exe bug bar. We're just really not going to take the risk on changing CMD's behavior at this point. Every time we do, it creates a chain of events that usually lead to a revert and servicing. We recommend that you work around this in another way and/or migrate to a different scripting language like PowerShell. Thanks.