cmd: add environment variable to disable/enable 'Terminate batch job (Y/N)?' confirmation

[mikemaccana]

(migrated from PowerShell/PowerShell#7080 per @BrucePay's suggestion)

When I cancel a cmd script with Ctrl C, the following dialog pops up:

Terminate batch job (Y/N)?

I understand why this exists, but I'd also like the option to disable it, so cancelling cancels immediately. Judging by Stack Overflow, I'm not the only one

So a request: could we have an environment variable to control this?

[zadjii-msft]

@paulcam206 as the cmd guru, he'll probably have more thoughts on the matter.

I really highly doubt that we could just add an env var to disable this, but it is an interactive-only scenario, so it might be possible...

[mikemaccana]

Thanks for responding Mike! Any specific reason why checking a flag would be so difficult? Looking forward to seeing what @paulcam206 thinks.

[zadjii-msft]

Honestly, changing cmd.exe at all is a bit terrifying. You can't be sure who in the world is actually depending on that behavior for some reason or another.

relevant xkcd

[paulcam206]

it's possible that this could be done with something like a new setlocal setting. however, we've not added one of these in a long time. that said, I'll file an item on our backlog to investigate :)

[mikemaccana]

Ack @zadjii-msft - not proposing to change the default, so should only affect people who've explicitly set some very long string.

@paulcam206 thanks! I'm not sure about how setlocal works - my real experience of cmd is launching cmd files from powershell). Would I still be able to do this in Powershell:

$env:TERMINATE_IMMEDIATELY='yes'
somefile.cmd

Then press Ctrl C when I need to and have it work?

[miniksa]

setlocal doesn't behave the same way as an environment variable. It's a thing that would have to be put in at the top of the batch script that is somefile.cmd as one of its first commands to adjust the way that one specific batch file is processed by the cmd.exe engine. That's probably not suitable for your needs, but that's the way we have to go.

I don't think anyone is disagreeing with you, @mikemaccana, that this would be a five minute development change to read that environment variable and change the behavior of cmd.exe. It absolutely would be a tiny development time.

It's just that from our experience, we know there's going to be a 3-24 month bug tail here where we get massive investigation callbacks by some billion dollar enterprise customer who for whatever reason was already using the environment variable we pick for another purpose. Their script that they give their rank-and-file folks will tell them to press Ctrl+C at some point in the batch script to do whatever happens, it will do something different, those people will notice the script doesn't match the computer anymore. They will then halt the production line and tell their supervisor. The supervisor tells some director. Their director comes screaming at their Microsoft enterprise support contract person that we've introduced a change to the OS that is costing them millions if not billions of dollars in shipments per month. Our directors at Microsoft then come bashing down our doors angry with us and make us fix it ASAP or revert it, we don't get to go home at 5pm to our families or friends because we're fixing it, we get stressed the heck out, we have to spin up servicing potentially for already shipped operating systems which is expensive and headache-causing...etc.

We can see this story coming a million miles away because it has happened before with other 'tiny' change we've been asked to make to cmd.exe in the past few years.

I would just ask you to understand that cmd.exe is very, very much in a maintenance mode and I just want to set expectations here. We maintain it, yes. We have a renewed interest in command-line development, yes. But our focuses are revolving around improving the terminal and platform itself and bringing modern, supported shells to be the best they can be on Windows. Paul will put this on the backlog of things that people want in cmd.exe, yes. But it will sink to the bottom of the backlog because changing cmd.exe is our worst nightmare as its compatibility story is among the heaviest of any piece of the operating system.

I would highly recommend that Gulp convert to using PowerShell scripts and that if such an issue exists with PowerShell, that we get their modern, supported, and better-engineered platform to support the scenario. I don't want you to sit around waiting for cmd.exe to change this because it's really not going to happen faster than that script could be converted to ps1 and it fixed in PowerShell Core (if that's even a problem in that world.)

[zadjii-msft]

oh god I'm having ptsd flashbacks just reading that

[paulcam206]

yep

[bitcrazed]

@ALL - @miniksa @zadjii-msft and @paulcam206 are not kidding - the unexpected impact of even the smallest change to Cmd has resulted in calamities, misfortune, lost-weekends and evenings, stress and unnecessary turmoil.

Cmd is in maintenance mode. It isn't being deprecated or removed - in fact, I doubt it'll EVER be removed from Windows, but do understand that Cmd is extremely fragile and difficult to change.

I keep saying it, and now that PowerShell is available almost everywhere - even Linux & macOS - it's more true than ever:

If you're writing Windows Command-Line scripts today, they should be PowerShell scripts wherever possible

[mikemaccana]

Thanks @bitcrazed. I appreciate the testimony directly from the horse's mouth - I've submitted a PR to one of the many node projects that use cmd scripts, with a .ps1 replacement. Hopefully it gets accepted and we start moving node onto a more supported scripting language.

[parkovski]

It seems to me that cmd scripts are generally used in the place of exe symlinks and shebang scripts, which PowerShell is not a good replacement for - if you switch out yarn.cmd for yarn.ps1, that's fine if you're already in PowerShell, but if you're in cmd, or some other shell, or using ShellExecute or some scripting language's equivalent, you have to write pwsh -c yarn, so then why not get rid of the script altogether and do node yarn.js?

For this type of thing, we're pretty much stuck with something in PATHEXT, and I think cmd is the only console interpreter in there.