cmd: add environment variable to disable/enable &#39;Terminate batch job (Y/N)?&#39; confirmation #319

@be5invis commented on GitHub (Sep 29, 2018):

@bitcrazed
But, executing PowerShell script is not enabled by default.

@be5invis commented on GitHub (Sep 29, 2018): @bitcrazed But, executing PowerShell script is not enabled by default.

claunia commented

@be5invis commented on GitHub (Sep 29, 2018):

@parkovski
An interesting idea would be using WSF/WSH files.

@be5invis commented on GitHub (Sep 29, 2018): @parkovski An interesting idea would be using WSF/WSH files.

claunia commented

@Jack-Works commented on GitHub (Apr 2, 2019):

Any progress on this issue?

@Jack-Works commented on GitHub (Apr 2, 2019): Any progress on this issue?

claunia commented

2026-01-30 21:48:50 +00:00

@zadjii-msft commented on GitHub (Apr 2, 2019):

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.

We're not going to make changes to cmd.exe to support this scenario.

@zadjii-msft commented on GitHub (Apr 2, 2019): > `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. We're not going to make changes to cmd.exe to support this scenario.

claunia commented

@Jack-Works commented on GitHub (Apr 2, 2019):

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.

We're not going to make changes to cmd.exe to support this scenario.

Okay, I understand this.
But, is there an unofficial / hack solution to this?
I searched the web and only found someone patching binary to do this.
Unfortunately, that only works for Windows XP to and Windows 7

Then I found another project, https://github.com/sgraham/cmdEx
Only works for Windows 8.1 32bit

:(

@Jack-Works commented on GitHub (Apr 2, 2019): > > `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. > > We're not going to make changes to cmd.exe to support this scenario. Okay, I understand this. But, is there an unofficial / hack solution to this? I searched the web and only found someone patching binary to do this. Unfortunately, that only works for Windows XP to and Windows 7 Then I found another project, https://github.com/sgraham/cmdEx Only works for Windows 8.1 32bit :(

claunia commented

2026-01-30 21:48:50 +00:00

@be5invis commented on GitHub (Apr 2, 2019):

Something replacing .cmd and .bat?
PS1 is too complex and too slow.

发件人: Jack Works notifications@github.com
发送时间: Tuesday, April 2, 2019 10:06:41 PM
收件人: Microsoft/console
抄送: Renzhi Li; Comment
主题: Re: [Microsoft/console] cmd: add environment variable to disable/enable 'Terminate batch job (Y/N)?' confirmation (#217)

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.

We're not going to make changes to cmd.exe to support this scenario.

Okay, I understand this.
But, is there an unofficial / hack solution to this?
I searched the web and only found someone patching binary to do this.
Unfortunately, that only works for Windows XP to and Windows 7

Then I found another project, https://github.com/sgraham/cmdEx https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsgraham%2FcmdEx&data=02%7C01%7CRenzhi.Li%40microsoft.com%7Cea8b6c7e4ee14e5d780d08d6b7746eb7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636898108031211694&sdata=Id%2FYm1klHq6nHjQY50Uph9FdTWHsGsTXRYOODmYox8s%3D&reserved=0
Only works for Windows 8.1 32bit

:(

―
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoft%2Fconsole%2Fissues%2F217%23issuecomment-479012154&data=02%7C01%7CRenzhi.Li%40microsoft.com%7Cea8b6c7e4ee14e5d780d08d6b7746eb7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636898108031211694&sdata=dVp4NGya3W6yH7NMFgg87lb38fhjj7r%2F%2Fmr3xTTwHuM%3D&reserved=0, or mute the threadhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAAOp25uHVKve6DUbDGCsqYMg3lRvJlcDks5vc2PxgaJpZM4VGR0n&data=02%7C01%7CRenzhi.Li%40microsoft.com%7Cea8b6c7e4ee14e5d780d08d6b7746eb7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636898108031221686&sdata=jVKSOX8R0tjLrlcqejdOgDPJ4pTVFg9FhuzSKS7fPAc%3D&reserved=0.

@be5invis commented on GitHub (Apr 2, 2019): Something replacing .cmd and .bat? PS1 is too complex and too slow. ________________________________ 发件人: Jack Works <notifications@github.com> 发送时间: Tuesday, April 2, 2019 10:06:41 PM 收件人: Microsoft/console 抄送: Renzhi Li; Comment 主题: Re: [Microsoft/console] cmd: add environment variable to disable/enable 'Terminate batch job (Y/N)?' confirmation (#217) 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. We're not going to make changes to cmd.exe to support this scenario. Okay, I understand this. But, is there an unofficial / hack solution to this? I searched the web and only found someone patching binary to do this. Unfortunately, that only works for Windows XP to and Windows 7 Then I found another project, https://github.com/sgraham/cmdEx<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsgraham%2FcmdEx&data=02%7C01%7CRenzhi.Li%40microsoft.com%7Cea8b6c7e4ee14e5d780d08d6b7746eb7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636898108031211694&sdata=Id%2FYm1klHq6nHjQY50Uph9FdTWHsGsTXRYOODmYox8s%3D&reserved=0> Only works for Windows 8.1 32bit :( ― You are receiving this because you commented. Reply to this email directly, view it on GitHub<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoft%2Fconsole%2Fissues%2F217%23issuecomment-479012154&data=02%7C01%7CRenzhi.Li%40microsoft.com%7Cea8b6c7e4ee14e5d780d08d6b7746eb7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636898108031211694&sdata=dVp4NGya3W6yH7NMFgg87lb38fhjj7r%2F%2Fmr3xTTwHuM%3D&reserved=0>, or mute the thread<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAAOp25uHVKve6DUbDGCsqYMg3lRvJlcDks5vc2PxgaJpZM4VGR0n&data=02%7C01%7CRenzhi.Li%40microsoft.com%7Cea8b6c7e4ee14e5d780d08d6b7746eb7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636898108031221686&sdata=jVKSOX8R0tjLrlcqejdOgDPJ4pTVFg9FhuzSKS7fPAc%3D&reserved=0>.

claunia commented

2026-01-30 21:48:50 +00:00

@miniksa commented on GitHub (Apr 2, 2019):

@Jack-Works, we are not in the business of developing or propagating unofficial hacks to our software. If you figure something out, more power to you. But we can't help you there.

@be5invis, I'm sure the Powershell team would be happy to accept your feedback and improve their product. They are the Microsoft team that has funding for the interactive shell space.

@miniksa commented on GitHub (Apr 2, 2019): @Jack-Works, we are not in the business of developing or propagating unofficial hacks to our software. If you figure something out, more power to you. But we can't help you there. @be5invis, I'm sure the Powershell team would be happy to accept your feedback and improve their product. They are the Microsoft team that has funding for the interactive shell space.

claunia commented

@mikemaccana commented on GitHub (Apr 5, 2019):

As everyone else says, the fix for this is moving from cmd to ps1. @bitcrazed mentioned he's going to publish a blog post recommending people do this a little while ago (since a lot of node folks etc are producing new cmd scripts).

While we wait for peopel to start distributing ps1 scripts, the safest bet to handle leftover cmds is to etiher press Ctrl C twice or use something like Hyper's https://hyper.is/plugins/hyper-yes

@mikemaccana commented on GitHub (Apr 5, 2019): As everyone else says, the fix for this is moving from `cmd` to `ps1`. @bitcrazed mentioned he's going to publish a blog post recommending people do this a little while ago (since a lot of node folks etc are producing new `cmd` scripts). While we wait for peopel to start distributing `ps1` scripts, the safest bet to handle leftover `cmd`s is to etiher press Ctrl C twice or use something like Hyper's https://hyper.is/plugins/hyper-yes

claunia commented

@musm commented on GitHub (Apr 11, 2019):

I agree with the problem with using powershell here instead of cmd; which I agree would be ideal, except it's far too slow in its initialization time. Even more unfortunately the new pwsh is even slower to initialize. This is something I opened an issue about, but the situation is not likely to be improved https://github.com/PowerShell/PowerShell/issues/6443.

Startup latency:
466 ms POWERSHELL
42 ms CMD

500 ms is way too long for a script, hence I'm not sure the solution to use ps1 is actually reasonable.

Here's the script to test start up latency

> function time($block) {
    $sw = [Diagnostics.Stopwatch]::StartNew()
    &$block
    $sw.Stop()
    $sw.Elapsed
}

> time {powershell -NoProfile -c exit}
> time {cmd-NoProfile -c exit}

@musm commented on GitHub (Apr 11, 2019): I agree with the problem with using powershell here instead of cmd; which I agree would be ideal, **except** it's far too slow in its initialization time. Even more unfortunately the new pwsh is even slower to initialize. This is something I opened an issue about, but the situation is not likely to be improved https://github.com/PowerShell/PowerShell/issues/6443. Startup latency: 466 ms POWERSHELL 42 ms CMD 500 ms is way too long for a script, hence I'm not sure the solution to use ps1 is actually reasonable. Here's the script to test start up latency ```sh > function time($block) { $sw = [Diagnostics.Stopwatch]::StartNew() &$block $sw.Stop() $sw.Elapsed } > time {powershell -NoProfile -c exit} > time {cmd-NoProfile -c exit} ```

claunia commented

@miniksa commented on GitHub (Apr 11, 2019):

CMD.exe is not getting updated. I don't know how to stress that any further.

@miniksa commented on GitHub (Apr 11, 2019): CMD.exe is not getting updated. I don't know how to stress that any further.

claunia commented

@musm commented on GitHub (Apr 11, 2019):

Sorry I should've been made it clear that I know that cmd.exe won't be updated. I wanted to highlight the issues with the powershell recommendation, compared to using cmd.exe, and that hopefully an another solution may exist.

@musm commented on GitHub (Apr 11, 2019): Sorry I should've been made it clear that I know that cmd.exe won't be updated. I wanted to highlight the issues with the powershell recommendation, compared to using cmd.exe, and that hopefully an another solution may exist.

claunia commented

@be5invis commented on GitHub (Apr 12, 2019):

@miniksa @musm @zadjii-msft

.PS1's problem:

PowerShell is still 10× times slower than CMD.
Scripts are disabled by default!

From my view, the best solution for “.cmd stubs” might be generating an EXE stub (like Shimmy), if it does not irrate anti-malware softwares. A code signature may reduce such false positives (sign the code part and put the command line pattern into the rest places.)

~~For npm, an interesting solution may be using .js files directly and launch them with WSH -- and then forward it to the real .js entry points.~~ UPDATE: It doesn't work. WSH starts the Node process in a new window.

@be5invis commented on GitHub (Apr 12, 2019): @miniksa @musm @zadjii-msft `.PS1`'s problem: - PowerShell is still 10× times slower than CMD. - Scripts are disabled by default! From my view, the best solution for “`.cmd` stubs” might be generating an EXE stub (like [Shimmy](https://github.com/pfmoore/shimmy)), if it does not irrate anti-malware softwares. A code signature may reduce such false positives (sign the code part and put the command line pattern into the rest places.) <s>For `npm`, an interesting solution may be using `.js` files directly and launch them with WSH -- and then forward it to the real `.js` entry points.</s> UPDATE: It doesn't work. WSH starts the Node process in a new window.

claunia commented

@parkovski commented on GitHub (Apr 19, 2019):

I don't know all the details of this and would be curious to hear some more informed opinions, but:

PE files (.exe) start with the "magic number" MZ.
Executable shell scripts with a shebang also have a two byte magic number, #!.

Is there any way to inform the loader that when the magic number is #!, it will be passed to the interpreter specified in the rest of the line, like linux shebang files? As far as I can tell, this would solve all the issues regarding slow shell startup time (we bypass PowerShell and cmd altogether), the PATHEXT issue that exists with .ps1 files, the pain point of trying to launch them from WSL, and any weird behavior caused by using cmd.exe for this purpose.

It also seems to me, although I'm certainly not an expert, that there wouldn't really be a security risk here, as a regular binary exe could do anything and more that a shebang script could, and if signing was enabled for these scripts, I can't see how they would be any different than any other exes.

@parkovski commented on GitHub (Apr 19, 2019): I don't know all the details of this and would be curious to hear some more informed opinions, but: - PE files (.exe) start with the "magic number" `MZ`. - Executable shell scripts with a shebang also have a two byte magic number, `#!`. Is there any way to inform the loader that when the magic number is `#!`, it will be passed to the interpreter specified in the rest of the line, like linux shebang files? As far as I can tell, this would solve all the issues regarding slow shell startup time (we bypass PowerShell and cmd altogether), the `PATHEXT` issue that exists with `.ps1` files, the pain point of trying to launch them from WSL, and any weird behavior caused by using cmd.exe for this purpose. It also seems to me, although I'm certainly not an expert, that there wouldn't really be a security risk here, as a regular binary exe could do anything and more that a shebang script could, and if signing was enabled for these scripts, I can't see how they would be any different than any other exes.

claunia commented

@oising commented on GitHub (Apr 19, 2019):

@parkovski This wouldn't be safe at all since Windows has no equivalent of the execute bit (chmod +x).

@oising commented on GitHub (Apr 19, 2019): @parkovski This wouldn't be safe at all since Windows has no equivalent of the execute bit (chmod +x).

claunia commented

@parkovski commented on GitHub (Apr 19, 2019):

Why not? .exe is the execute bit. Totally open to corrections, but a shebang exe would be basically equivalent to a shim exe that just launches another process, without the overhead of actually loading a launcher process. All other security features that already apply to exes would still apply to this type; it's just a special form where the shebang line replaces the exe name, just as .bat automatically invokes cmd.exe, or a shim exe can "fork out" to another exe.

As in, what is the difference between these two:

foo.exe: #!node ....
foo.exe: Invokes node with the text stored somewhere in the file that can be extracted with WinAPIs.

I don't see any difference, except that one is easily human creatable/editable, while the other requires a compiler.

Look at the scoop package manager's shims. They are a hack around this - an exe that loads a text file and launches it. I don't see how extending the exe could possibly be any more dangerous than what is already available.

@parkovski commented on GitHub (Apr 19, 2019): Why not? `.exe` is the execute bit. Totally open to corrections, but a shebang exe would be basically equivalent to a shim exe that just launches another process, without the overhead of actually loading a launcher process. All other security features that already apply to exes would still apply to this type; it's just a special form where the shebang line replaces the exe name, just as `.bat` automatically invokes `cmd.exe`, or a shim exe can "fork out" to another exe. As in, what is the difference between these two: - foo.exe: `#!node ....` - foo.exe: Invokes `node` with the text stored somewhere in the file that can be extracted with WinAPIs. I don't see any difference, except that one is easily human creatable/editable, while the other requires a compiler. Look at the scoop package manager's shims. They are a hack around this - an exe that loads a text file and launches it. I don't see how extending the exe could possibly be any more dangerous than what is already available.

claunia commented

@oising commented on GitHub (Apr 19, 2019):

Oh, I see -- you're not advocating allowing any file to be a shebang script. I can't speak to the can of worms that would open, nor do I ever think this would be considered but it's interesting to ponder nonetheless.

@oising commented on GitHub (Apr 19, 2019): Oh, I see -- you're not advocating allowing any file to be a shebang script. I can't speak to the can of worms that would open, nor do I ever think this would be considered but it's interesting to ponder nonetheless.

claunia commented

@parkovski commented on GitHub (Apr 19, 2019):

Yeah, I'm not too optimistic about this actually being embedded in Windows, but if we were allowed to have !# exes (and only .exes), I think that would solve a lot of these weird cmd script issues.

@parkovski commented on GitHub (Apr 19, 2019): Yeah, I'm not too optimistic about this actually being embedded in Windows, but if we were allowed to have `!#` exes (and only `.exe`s), I think that would solve a lot of these weird cmd script issues.

claunia commented

@albertjan commented on GitHub (May 7, 2019):

I'm just going to leave this here :D https://github.com/sgraham/cmdEx for people that don't accept reality and want to substitute it with something else.

@albertjan commented on GitHub (May 7, 2019): I'm just going to leave this here :D https://github.com/sgraham/cmdEx for people that don't accept reality and want to substitute it with something else.

claunia commented

@giggio commented on GitHub (May 24, 2019):

You could just open source cmd and somebody would just produce a highly compatible (but not fully), and with these tiny new things we all want. A cmd2, let's say, or even a cmd we could replace the original one with. That big enterprise will never see it, and we all get to live a little bit better.

@giggio commented on GitHub (May 24, 2019): You could just open source cmd and somebody would just produce a highly compatible (but not fully), and with these tiny new things we all want. A cmd2, let's say, or even a cmd we could replace the original one with. That big enterprise will never see it, and we all get to live a little bit better.

claunia commented

2026-01-30 21:48:54 +00:00

@DHowett-MSFT commented on GitHub (May 24, 2019):

We've got enough on our hands with the new open-source Terminal. Thanks for the suggestion, though!

@DHowett-MSFT commented on GitHub (May 24, 2019): We've got enough on our hands with the new open-source Terminal. Thanks for the suggestion, though!

claunia commented

@SteveDrakey commented on GitHub (Jun 26, 2019):

Personally, I would like to see this feature tied somehow to developer mode
developer mode could unlock more options not just side loading apps. If the big corporation is running servers in developer mode then well... (You could couple dev mode with the above suggestions)

I run npm start
hit CTRL C, and I get the Terminate Batch Job Y/N I just HIT CTRL C why are you asking me this
If I hit N it does the same as Y anyways in this example.

@SteveDrakey commented on GitHub (Jun 26, 2019): Personally, I would like to see this feature tied somehow to `developer mode` `developer mode` could unlock more options not just side loading apps. If the big corporation is running servers in developer mode then well... (You could couple dev mode with the above suggestions) I run `npm start` hit CTRL C, and I get the `Terminate Batch Job Y/N` **I just HIT CTRL C why are you asking me this** If I hit N it does the same as Y anyways in this example.

claunia commented

2026-01-30 21:48:54 +00:00

@eryksun commented on GitHub (Dec 30, 2019):

@parkovski This wouldn't be safe at all since Windows has no equivalent of the execute bit (chmod +x).

Filesystems that support ACLs (i.e. those with the flag FILE_PERSISTENT_ACLS), such as NTFS (required for the system drive), have equivalent FILE_EXECUTE discretionary access control. CreateProcessW will fail with access denied (5) if the caller doesn't have execute access.

For example, grant the owner of "spam.exe" generic execute access and the right to modify the discretionary ACL: icacls "spam.exe" /grant *OW:(GE,WDAC). (The File object type maps GENERIC_EXECUTE access to FILE_EXECUTE | FILE_READ_ATTRIBUTES | READ_CONTROL | SYNCHRONIZE. "OW" is SDDL for the "OWNER RIGHTS" security principle.)

We can also set SYSTEM_MANDATORY_LABEL_NO_EXECUTE_UP mandatory access restriction for caller's at a lower integrity level than that of the file, but Windows doesn't include a command-line utility to modify the no-execute-up flag in a file's mandatory label.

One major problem is portable filesystems such as FAT32 and exFAT that lack security. You'd need a policy to disable shebang support for these filesystems. The next problem is that the default ACLs in Windows liberally grant execute access based on rules inherited from the root directory and the primary system directories (e.g. "Windows", "Program Files", "ProgramData", "Users"). Removing inherited execute access would require assigning custom security instead of relying completely on inheritance.

Filetypes that ShellExecuteExW passes directly to CreateProcessW use "%1" %* as their command template, where "%1" is the file itself. This is currently used for ".EXE", ".COM", ".CMD" and ".BAT" files. In principle this can be extended to filenames that have no extension. To the shell this is ".", because "spam" and "spam." are equivalent in DOS.

@eryksun commented on GitHub (Dec 30, 2019): > @parkovski This wouldn't be safe at all since Windows has no equivalent of the execute bit (chmod +x). Filesystems that support ACLs (i.e. those with the flag `FILE_PERSISTENT_ACLS`), such as NTFS (required for the system drive), have equivalent `FILE_EXECUTE` discretionary access control. `CreateProcessW` will fail with access denied (5) if the caller doesn't have execute access. For example, grant the owner of "spam.exe" generic execute access and the right to modify the discretionary ACL: `icacls "spam.exe" /grant *OW:(GE,WDAC)`. (The File object type maps `GENERIC_EXECUTE` access to `FILE_EXECUTE | FILE_READ_ATTRIBUTES | READ_CONTROL | SYNCHRONIZE`. "OW" is SDDL for the "OWNER RIGHTS" security principle.) We can also set `SYSTEM_MANDATORY_LABEL_NO_EXECUTE_UP` mandatory access restriction for caller's at a lower integrity level than that of the file, but Windows doesn't include a command-line utility to modify the no-execute-up flag in a file's mandatory label. One major problem is portable filesystems such as FAT32 and exFAT that lack security. You'd need a policy to disable shebang support for these filesystems. The next problem is that the default ACLs in Windows liberally grant execute access based on rules inherited from the root directory and the primary system directories (e.g. "Windows", "Program Files", "ProgramData", "Users"). Removing inherited execute access would require assigning custom security instead of relying completely on inheritance. Filetypes that `ShellExecuteExW` passes directly to `CreateProcessW` use `"%1" %*` as their command template, where `"%1"` is the file itself. This is currently used for ".EXE", ".COM", ".CMD" and ".BAT" files. In principle this can be extended to filenames that have no extension. To the shell this is ".", because "spam" and "spam." are equivalent in DOS.

claunia commented

2026-01-30 21:48:54 +00:00

@be5invis commented on GitHub (Dec 30, 2019):

@parkovski
Another option may be let npm, etc. to generate real EXE files that simply launches node whatever. There should be able to create some trick to keep the EXE signed.

@be5invis commented on GitHub (Dec 30, 2019): @parkovski Another option may be let `npm`, etc. to generate real EXE files that simply launches `node whatever`. There should be able to create some trick to keep the EXE signed.

claunia commented

@ilya-g commented on GitHub (Jan 10, 2020):

billion dollar enterprise customer who for whatever reason was already using the environment variable we pick for another purpose

@miniksa Is it possible to introduce a flag in the registry instead of an environment variable for that purpose? As far as I can see, that would address this concern.

@ilya-g commented on GitHub (Jan 10, 2020): > billion dollar enterprise customer who for whatever reason was already using the environment variable we pick for another purpose @miniksa Is it possible to introduce a flag in the registry instead of an environment variable for that purpose? As far as I can see, that would address this concern.

claunia commented

@zadjii-msft commented on GitHub (Jan 10, 2020):

Then there's just another billion-dollar enterprise out there that for some unknowable reason is already setting that flag in the registry for some other purpose, and will run into the same issues.

@zadjii-msft commented on GitHub (Jan 10, 2020): Then there's just another billion-dollar enterprise out there that for some unknowable reason is already setting that flag in the registry for some other purpose, and will run into the same issues.

claunia commented

@armordog commented on GitHub (Jan 10, 2020):

Then there's just another billion-dollar enterprise out there that for some unknowable reason is already setting that flag in the registry for some other purpose, and will run into the same issues.

Surely you're kidding.

This would prevent any changes to any aspect of Windows.

@armordog commented on GitHub (Jan 10, 2020): > Then there's just another billion-dollar enterprise out there that for some unknowable reason is already setting that flag in the registry for some other purpose, and will run into the same issues. Surely you're kidding. This would prevent _any_ changes to any aspect of Windows.

claunia commented

@be5invis commented on GitHub (Jan 11, 2020):

Then there's just another billion-dollar enterprise out there that for some unknowable reason is already setting that flag in the registry for some other purpose, and will run into the same issues.

GUID should be good for this 🙂
Nobody can predict GUID

@be5invis commented on GitHub (Jan 11, 2020): > Then there's just another billion-dollar enterprise out there that for some unknowable reason is already setting that flag in the registry for some other purpose, and will run into the same issues. GUID should be good for this 🙂 Nobody can predict GUID

claunia commented

@eryksun commented on GitHub (Jan 12, 2020):

Then there's just another billion-dollar enterprise out there that for some unknowable reason is already setting that flag in the registry for some other purpose, and will run into the same issues.

No enterprise has any business adding custom values to CMD's configuration key, "[HKLM|HKCU]\Software\Microsoft\Command Processor". Surely you have to draw some reasonable lines in the sand with your customers.

@eryksun commented on GitHub (Jan 12, 2020): > Then there's just another billion-dollar enterprise out there that for some unknowable reason is already setting that flag in the registry for some other purpose, and will run into the same issues. No enterprise has any business adding custom values to CMD's configuration key, "[HKLM|HKCU]\\Software\\Microsoft\\Command Processor". Surely you have to draw some reasonable lines in the sand with your customers.

claunia commented

@parkovski commented on GitHub (Jan 12, 2020):

This looks to me like a case of the emacs spacebar. Obviously nobody wants to potentially deal with these kind of issues. On the other hand, this is a stupid feature that everyone wants to turn off globally. I agree that an environment variable is risky, but the registry key strikes me as the all-around best solution to this.

Cmd has been changed - it turns on ENABLE_VIRTUAL_TERMINAL_PROCESSING. Maybe other things as well, but I at least know of this one.
This change would be extremely small in scope and would make at least me disproportionately happy.
A setlocal would at least be an option, but every script would have to be updated so it doesn't seem like a great way to do this.
The registry is already used for tons of potential breaking change backcompat type switches.
This "feature" is so obnoxious that if there were a way to bribe you guys I'd chip in a couple dollars for the cause.

I understand the fear of changing cmd and I can't be upset with you guys if you don't change this (although I can certainly be upset at whoever introduced it). If it did happen though, you guys are already minor personal heroes, but I guess it'd be an extra point there, and I think that's all I got.

@parkovski commented on GitHub (Jan 12, 2020): This looks to me like a case of the [emacs spacebar](https://xkcd.com/1172/). Obviously nobody wants to potentially deal with these kind of issues. On the other hand, this is a stupid feature that everyone wants to turn off globally. I agree that an environment variable is risky, but the registry key strikes me as the all-around best solution to this. - Cmd _has_ been changed - it turns on `ENABLE_VIRTUAL_TERMINAL_PROCESSING`. Maybe other things as well, but I at least know of this one. - This change would be extremely small in scope and would make at least me disproportionately happy. - A setlocal would at least be an option, but every script would have to be updated so it doesn't seem like a great way to do this. - The registry is already used for tons of potential breaking change backcompat type switches. - This "feature" is so obnoxious that if there were a way to bribe you guys I'd chip in a couple dollars for the cause. I understand the fear of changing cmd and I can't be upset with you guys if you don't change this (although I can certainly be upset at whoever introduced it). If it did happen though, you guys are already minor personal heroes, but I guess it'd be an extra point there, and I think that's all I got.

claunia commented

@zadjii-msft commented on GitHub (Jan 13, 2020):

I was 85% joking, and 15% "we've been burned literally every time we've touched cmd.exe so it's almost certainly not happening"

Even the ENABLE_VIRTUAL_TERMINAL_PROCESSING required us to go back and change it such that cmd.exe only enables that flag for itself, and disables it again for child processes.

@zadjii-msft commented on GitHub (Jan 13, 2020): _I was 85% joking, and 15% "we've been burned literally every time we've touched cmd.exe so it's almost certainly not happening"_ Even the `ENABLE_VIRTUAL_TERMINAL_PROCESSING` required us to go back and change it such that `cmd.exe` only enables that flag for itself, and disables it again for child processes.

claunia commented

@arcanis commented on GitHub (Sep 17, 2020):

@zadjii-msft Please correct me if I'm wrong (seriously! I hope I am 😄), but I think Powershell isn't a good general option. Even if we add .ps1 in the PATHEXT, it seems that the default file association opens it with Notepad or VS, which prevents it from being a replacement for cmd being used as a kind of "enhanced symbolic link" (we pass additional arguments).

It's your project, and any change would be your responsibility so I understand if it doesn't happen, but the setlocal option sounded interesting (it requires scripts to opt-in, but precisely it requires scripts to opt-in), and would definitely be useful to us.

@arcanis commented on GitHub (Sep 17, 2020): @zadjii-msft Please correct me if I'm wrong (seriously! I hope I am 😄), but I think Powershell isn't a good general option. Even if we add `.ps1` in the PATHEXT, it seems that the default file association opens it with Notepad or VS, which prevents it from being a replacement for cmd being used as a kind of "enhanced symbolic link" (we pass additional arguments). It's your project, and any change would be your responsibility so I understand if it doesn't happen, but the [`setlocal` option](https://github.com/microsoft/terminal/issues/217#issuecomment-404240443) sounded interesting (it requires scripts to opt-in, but precisely *it requires scripts to opt-in*), and would definitely be useful to us.

claunia commented

@arcanis commented on GitHub (Nov 25, 2020):

Of note, we tried these past months to use a binary to workaround this problem, but it unfortunately doesn't work for some of our users that are in locked Windows environments. Even signing our jumper wouldn't help in those circumstances ...

@arcanis commented on GitHub (Nov 25, 2020): Of note, we tried these past months to use [a binary](https://github.com/merceyz/binjumper) to workaround this problem, but it unfortunately doesn't work for some of our users that are in locked Windows environments. Even signing our jumper wouldn't help in those circumstances ...

claunia commented

@rivy commented on GitHub (Dec 3, 2020):

@arcanis , I've realized that a known quirk of CMD can be used as a work-around.

GOTO undefined label is a fatal error. It immediately terminates batch processing, but the currently executing block of code that has already been parsed continues to completion. However, the remainder of the code is executed using a command line context instead of a batch context.

dbenham (commenting on this StackOverflow answer)

I've used this to work around another annoying CMD bug (the fact that exit /b 1 within a script doesn't set the process exit code unless the script in question is called via call SCRIPT, which is obviously uncontrollable by the script itself; further explanation (and fix) is within the commentary for commit 9a7db966 that I added to pl2bat.

But you can use the same quirk here to kill the calling script, avoiding any "Terminate batch job (Y/N)?" prompt originating from the calling script, while still executing the remainder of the code in the parsed unit.

@rem ...
goto #_undefined_# 2>NUL || title %COMSPEC% & "%PROG_NAME%" %ARGS%
@rem ...

The title %COMSPEC% command is included in order to work-around the fact that using this prevents the caller from resetting the window title to a prior value which can lead to ever-expanding window titles. I think it's a minor inconvenience for the benefits gained: both the suppression of "Terminate..." and correct process exit values, no matter how the script is called.

In example, I'm using the following code as a replacement for the npm shim for my installation of hexo...

@setLocal
@echo off
goto :_START_

:set_real_dp0
@rem:: ref: "https://stackoverflow.com/questions/19781569/cmd-failure-of-d0-when-call-quotes-the-name-of-the-batch-file"
@rem:: ref: "https://stackoverflow.com/questions/12141482/what-is-the-reason-for-batch-file-path-referenced-with-dp0-sometimes-changes-o/26851883#26851883"
@rem:: ref: "https://www.dostips.com/forum/viewtopic.php?f=3&t=5057"
set dp0=%~dp0
set "dp0=%dp0:~0,-1%" &@rem:: clip trailing path separator
goto :EOF

:_START_
call :set_real_dp0

IF EXIST "%dp0%\node.exe" (
  SET "_prog=%dp0%\node.exe"
) ELSE (
  SET "_prog=node"
  SET PATHEXT=%PATHEXT:;.JS;=;%
)

endLocal & goto #_undefined_# 2>NUL || title %COMSPEC% & "%_prog%" "%dp0%\node_modules\hexo-cli\bin\hexo" %*

This construction of the hexo shim runs the node.exe executable in "command line mode" so any interrupts are not passed back up to the caller batch file. I've suggested that npm start using it as a template for future shims (see https://github.com/npm/cli/issues/969 and https://github.com/npm/cmd-shim/pull/46).

And, although I might personally consider this something of a "hack", it uses the standard, non-patched, CMD shell. So, it should be fair game. And, I expect, some billion-dollar customer will soon be using it somewhere (if they aren't already), so it should be stable. 😄

@rivy commented on GitHub (Dec 3, 2020): @arcanis , I've realized that a known quirk of CMD can be used as a work-around. > GOTO undefined label is a fatal error. It immediately terminates batch processing, but the currently executing block of code that has already been parsed continues to completion. However, the remainder of the code is executed using a command line context instead of a batch context. > - dbenham (commenting on this [StackOverflow answer](http://stackoverflow.com/questions/23327304/my-goto-redirect-is-not-working-but-works-with-echo/23327977#23327977)) I've used this to work around another annoying CMD bug (the fact that `exit /b 1` within a script doesn't set the process exit code *unless* the script in question is called via `call SCRIPT`, which is obviously uncontrollable by the script itself; further explanation (and fix) is within the commentary for [commit `9a7db966`](https://github.com/Perl-Toolchain-Gang/extutils-pl2bat/commit/9a7db96696ce52292cf5d3d6aa6c8dcd1a9a8744) that I added to [`pl2bat`](https://github.com/Perl-Toolchain-Gang/extutils-pl2bat). But you can use the same quirk here to kill the calling script, avoiding any "Terminate batch job (Y/N)?" prompt originating from the calling script, while still executing the remainder of the code in the parsed unit. ```batch @rem ... goto #_undefined_# 2>NUL || title %COMSPEC% & "%PROG_NAME%" %ARGS% @rem ... ``` The `title %COMSPEC%` command is included in order to work-around the fact that using this prevents the caller from resetting the window title to a prior value which can lead to ever-expanding window titles. I think it's a minor inconvenience for the benefits gained: both the suppression of "Terminate..." and correct process exit values, no matter how the script is called. In example, I'm using the following code as a replacement for the `npm` shim for my installation of `hexo`... ```batch @setLocal @echo off goto :_START_ :set_real_dp0 @rem:: ref: "https://stackoverflow.com/questions/19781569/cmd-failure-of-d0-when-call-quotes-the-name-of-the-batch-file" @rem:: ref: "https://stackoverflow.com/questions/12141482/what-is-the-reason-for-batch-file-path-referenced-with-dp0-sometimes-changes-o/26851883#26851883" @rem:: ref: "https://www.dostips.com/forum/viewtopic.php?f=3&t=5057" set dp0=%~dp0 set "dp0=%dp0:~0,-1%" &@rem:: clip trailing path separator goto :EOF :_START_ call :set_real_dp0 IF EXIST "%dp0%\node.exe" ( SET "_prog=%dp0%\node.exe" ) ELSE ( SET "_prog=node" SET PATHEXT=%PATHEXT:;.JS;=;% ) endLocal & goto #_undefined_# 2>NUL || title %COMSPEC% & "%_prog%" "%dp0%\node_modules\hexo-cli\bin\hexo" %* ``` This construction of the `hexo` shim runs the `node.exe` executable in "command line mode" so any interrupts are not passed back up to the caller batch file. I've suggested that `npm` start using it as a template for future shims (see <https://github.com/npm/cli/issues/969> and <https://github.com/npm/cmd-shim/pull/46>). And, although I might personally consider this something of a "hack", it uses the standard, non-patched, CMD shell. So, it should be fair game. And, I expect, some billion-dollar customer will soon be using it somewhere (if they aren't already), so it should be stable. 😄

claunia commented

@haseakash commented on GitHub (Sep 19, 2021):

Hello All ,

For anyone having issues ctr+c and break of batch. Then just use Keyfreez software.
you can run keyfreez at the start of the batch and end it using taskkill command at the end of batch

It disable whole keyboard.

@haseakash commented on GitHub (Sep 19, 2021): Hello All , For anyone having issues ctr+c and break of batch. Then just use **Keyfreez** software. you can run keyfreez at the start of the batch and end it using taskkill command at the end of batch It disable whole keyboard.

claunia commented

@noseratio commented on GitHub (Oct 11, 2021):

It appears like nobody wants to approach cmd.exe and touch it with a stick, because "we can break something". So cmd.exe has been in "maintenance mode", while its legitimate use keeps growing due to the popularity of CLI tools like Node.js, NPM, Deno etc., which heavily rely upon .CMD and .BAT files on Windows.

I struggle to come up with even a contrived scenario where the proper Ctrl+C handling (especially behind a feature flag) could possibly break any legacy scripts. OTOH, I can think of a magnitude of cases where the current behavior causes annoyances and harm.

E.g., when the following batch file is executing and I hit Ctrl+C trying to stop it, the infamous "Terminate batch job (Y/N)?" prompt is shown. I hit Ctrl+C again to escape, but the execution is continuing instead, deleting my GIF files:

@echo off
echo About to delete *.gif. Press Ctrl+C to stop
pause
del /q *.gif

For a more convincing example, speak to this person:

Luckily, there's new CreatePseudoConsole Win32 API that should make possible to create a proper shim for cmd.exe, to look for and intercept the "Terminate batch job (Y/N)?" prompt. Such shim can then be set as an active command shell via COMSPEC env variable.

When time allows, I'm going to explore this options, like I did to address another controversial behavior, paste-with-formatting-by-default.

@noseratio commented on GitHub (Oct 11, 2021): It appears like nobody wants to approach `cmd.exe` and touch it with a stick, because "we can break something". So `cmd.exe` has been in "maintenance mode", while its legitimate use keeps growing due to the popularity of CLI tools like Node.js, NPM, Deno etc., which heavily rely upon `.CMD` and `.BAT` files on Windows. I struggle to come up with even a contrived scenario where the proper Ctrl+C handling (especially behind a feature flag) could possibly break any legacy scripts. OTOH, I can think of a magnitude of cases where the current behavior causes annoyances and harm. E.g., when the following batch file is executing and I hit <kbd>Ctrl</kbd>+<kbd>C</kbd> trying to stop it, the infamous `"Terminate batch job (Y/N)?"` prompt is shown. I hit <kbd>Ctrl</kbd>+<kbd>C</kbd> again to escape, but the execution is continuing instead, deleting my GIF files: ``` @echo off echo About to delete *.gif. Press Ctrl+C to stop pause del /q *.gif ``` For a more convincing example, speak to [this person](https://superuser.com/questions/35698/how-to-supress-terminate-batch-job-y-n-confirmation#comment951864_35915): ![image](https://user-images.githubusercontent.com/4774875/136728604-40929d23-a2f6-4f79-8484-997c377530de.png) Luckily, there's new [`CreatePseudoConsole`](https://docs.microsoft.com/en-us/windows/console/createpseudoconsole) Win32 API that should make possible to create a proper shim for `cmd.exe`, to look for and intercept the `"Terminate batch job (Y/N)?"` prompt. Such shim can then be set as an active command shell via `COMSPEC` env variable. When time allows, I'm going to explore this options, like I did to address another controversial behavior, [paste-with-formatting-by-default](https://github.com/postprintum/devcomrade#what-is-it).

claunia commented

@miniksa commented on GitHub (Nov 3, 2021):

It appears like nobody wants to approach cmd.exe and touch it with a stick, because "we can break something". So cmd.exe has been in "maintenance mode", while its legitimate use keeps growing due to the popularity of CLI tools like Node.js, NPM, Deno etc., which heavily rely upon .CMD and .BAT files on Windows.

I struggle to come up with even a contrived scenario where the proper Ctrl+C handling (especially behind a feature flag) could possibly break any legacy scripts. OTOH, I can think of a magnitude of cases where the current behavior causes annoyances and harm.

E.g., when the following batch file is executing and I hit Ctrl+C trying to stop it, the infamous "Terminate batch job (Y/N)?" prompt is shown. I hit Ctrl+C again to escape, but the execution is continuing instead, deleting my GIF files:
@echo off
echo About to delete *.gif. Press Ctrl+C to stop
pause
del /q *.gif
For a more convincing example, speak to this person:

Luckily, there's new CreatePseudoConsole Win32 API that should make possible to create a proper shim for cmd.exe, to look for and intercept the "Terminate batch job (Y/N)?" prompt. Such shim can then be set as an active command shell via COMSPEC env variable.

When time allows, I'm going to explore this options, like I did to address another controversial behavior, paste-with-formatting-by-default.

This specific issue came in through Feedback Hub as well and I spent some time reproducing it. When I use conhost.exe, the first time I run the contrived script and do Ctrl+C twice, it exits properly. But subsequent runs, it deletes at the second one anyway. And when through Terminal... it just immediately goes to the second state and deletes.

So you've hit my interest further and I will be pulling this particular case out into a separate bug to figure out why the state changes and differs.

EDIT: MSFT:36733663

@miniksa commented on GitHub (Nov 3, 2021): > It appears like nobody wants to approach `cmd.exe` and touch it with a stick, because "we can break something". So `cmd.exe` has been in "maintenance mode", while its legitimate use keeps growing due to the popularity of CLI tools like Node.js, NPM, Deno etc., which heavily rely upon `.CMD` and `.BAT` files on Windows. > > I struggle to come up with even a contrived scenario where the proper Ctrl+C handling (especially behind a feature flag) could possibly break any legacy scripts. OTOH, I can think of a magnitude of cases where the current behavior causes annoyances and harm. > > E.g., when the following batch file is executing and I hit Ctrl+C trying to stop it, the infamous `"Terminate batch job (Y/N)?"` prompt is shown. I hit Ctrl+C again to escape, but the execution is continuing instead, deleting my GIF files: > > ``` > @echo off > echo About to delete *.gif. Press Ctrl+C to stop > pause > del /q *.gif > ``` > > For a more convincing example, speak to [this person](https://superuser.com/questions/35698/how-to-supress-terminate-batch-job-y-n-confirmation#comment951864_35915): > > ![image](https://user-images.githubusercontent.com/4774875/136728604-40929d23-a2f6-4f79-8484-997c377530de.png) > > Luckily, there's new [`CreatePseudoConsole`](https://docs.microsoft.com/en-us/windows/console/createpseudoconsole) Win32 API that should make possible to create a proper shim for `cmd.exe`, to look for and intercept the `"Terminate batch job (Y/N)?"` prompt. Such shim can then be set as an active command shell via `COMSPEC` env variable. > > When time allows, I'm going to explore this options, like I did to address another controversial behavior, [paste-with-formatting-by-default](https://github.com/postprintum/devcomrade#what-is-it). This specific issue came in through Feedback Hub as well and I spent some time reproducing it. When I use conhost.exe, the first time I run the contrived script and do Ctrl+C twice, it exits properly. But subsequent runs, it deletes at the second one anyway. And when through Terminal... it just immediately goes to the second state and deletes. So you've hit my interest further and I will be pulling this particular case out into a separate bug to figure out why the state changes and differs. EDIT: MSFT:36733663

claunia commented

@eryksun commented on GitHub (Nov 4, 2021):

When I use conhost.exe, the first time I run the contrived script and do Ctrl+C twice, it exits properly. But subsequent runs, it deletes at the second one anyway. And when through Terminal... it just immediately goes to the second state and deletes.

Canceling the batch termination prompt uses no as the default answer, and thus the script continues to run. In particular, cmd!PromptUser() handles a failed/canceled or empty (EOF) read by defaulting the answer to no. That's reasonable behavior in the general case (e.g. do not delete all the files in the "foo" directory for del foo). For the batch termination prompt, it probably would have been more reasonable to handle repeated Ctrl+C presses by terminating the script instead of canceling the prompt itself. (I'm thinking of a user frantically pressing Ctrl+C.) A parameter could have been added to PromptUser() to set the default answer instead of hard coding no as the default.

@eryksun commented on GitHub (Nov 4, 2021): > When I use conhost.exe, the first time I run the contrived script and do Ctrl+C twice, it exits properly. But subsequent runs, it deletes at the second one anyway. And when through Terminal... it just immediately goes to the second state and deletes. Canceling the batch termination prompt uses no as the default answer, and thus the script continues to run. In particular, `cmd!PromptUser()` handles a failed/canceled or empty (EOF) read by defaulting the answer to no. That's reasonable behavior in the general case (e.g. do not delete all the files in the "foo" directory for `del foo`). For the batch termination prompt, it probably would have been more reasonable to handle repeated Ctrl+C presses by terminating the script instead of canceling the prompt itself. (I'm thinking of a user frantically pressing Ctrl+C.) A parameter could have been added to `PromptUser()` to set the default answer instead of hard coding no as the default.

claunia commented

@simonbuchan commented on GitHub (Apr 5, 2022):

If MSFT is still watching this... what's the likelihood of being able to add a stub-specific replacement, and a new default entry to PATHEXT? I'm thinking the .cmd stub builders of the world like npm can instead emit a .some-stub-ext file that contains some trivial format like:

cd ..\..\some-package
exec node.exe
arg --some-option
forward-args
arg --
arg another-option

If it's part of windows, runs very fast, doesn't alter cmd.exe etc., that seems to mostly fix people's issues in this thread. It's mostly the change to the PATHEXT default that seems scary.

@simonbuchan commented on GitHub (Apr 5, 2022): If MSFT is still watching this... what's the likelihood of being able to add a stub-specific replacement, and a new default entry to PATHEXT? I'm thinking the `.cmd` stub builders of the world like `npm` can instead emit a `.some-stub-ext` file that contains some trivial format like: ``` cd ..\..\some-package exec node.exe arg --some-option forward-args arg -- arg another-option ``` If it's part of windows, runs very fast, doesn't alter `cmd.exe` etc., that seems to mostly fix people's issues in this thread. It's mostly the change to the PATHEXT default that seems scary.

claunia commented

@simonbuchan commented on GitHub (Apr 5, 2022):

Notably, .lnk files cover a lot of that usage, and seems to work quite well if you add them to PATHEXT. Are there issues with using .lnk as stubs?

@simonbuchan commented on GitHub (Apr 5, 2022): Notably, `.lnk` files cover a lot of that usage, and seems to work quite well if you add them to PATHEXT. Are there issues with using `.lnk` as stubs?

claunia commented

@doctorpangloss commented on GitHub (Oct 27, 2023):

@zadjii-msft can you hear the people chanting "Terminate batch job (Yes/No) has got to go!"?

One option is to break cmd.exe, forcing all shims to be authored anew. Because the prompt is kind of on the journey there already.

It's just that from our experience, we know there's going to be a 3-24 month bug tail here where...

Yeah. But like those people will keep using Windows, as much as you break it for them, but the people in this thread will keep switching to macOS. Kind of apples to oranges. It's been 5 years.

@doctorpangloss commented on GitHub (Oct 27, 2023): @zadjii-msft can you hear the people chanting "`Terminate batch job (Yes/No)` has got to go!"? One option is to break cmd.exe, forcing all shims to be authored anew. Because the prompt is kind of on the journey there already. > It's just that from our experience, we know there's going to be a 3-24 month bug tail here where... Yeah. But like those people will keep using Windows, as much as you break it for them, but the people in this thread will keep switching to macOS. Kind of apples to oranges. It's been 5 years.

claunia commented

@zadjii-msft commented on GitHub (Oct 27, 2023):

You're heard, for sure. But we're not planning on touching cmd.exe. Literally last week we had a P0 fire where we broke the core Windows build because we tried making what seemed like a trivial internal change to the CMD.exe code. It's literally burned us 100% of the times we've tried to touch it.

If you want a modern, updated shell on Windows, you should try out PowerShell 7. Or clink. Or yori.

@zadjii-msft commented on GitHub (Oct 27, 2023): You're heard, for sure. But we're not planning on touching `cmd.exe`. Literally _last week_ we had a P0 fire where we broke the core Windows build because we tried making what seemed like a trivial internal change to the CMD.exe code. It's literally burned us 100% of the times we've tried to touch it. If you want a modern, updated shell on Windows, you should try out [PowerShell 7](https://github.com/PowerShell/PowerShell). Or clink. Or yori.

claunia commented

@oising commented on GitHub (Oct 27, 2023):

You're heard, for sure. But we're not planning on touching cmd.exe. Literally last week we had a P0 fire where we broke the core Windows build because we tried making what seemed like a trivial internal change to the CMD.exe code. It's literally burned us 100% of the times we've tried to touch it.

If you want a modern, updated shell on Windows, you should try out PowerShell 7. Or clink. Or yori.

This would make a super interesting blog post (which you could point people to any time they ask this again) -- maybe ping Raymond Chen? :D

@oising commented on GitHub (Oct 27, 2023): > You're heard, for sure. But we're not planning on touching `cmd.exe`. Literally _last week_ we had a P0 fire where we broke the core Windows build because we tried making what seemed like a trivial internal change to the CMD.exe code. It's literally burned us 100% of the times we've tried to touch it. > > If you want a modern, updated shell on Windows, you should try out [PowerShell 7](https://github.com/PowerShell/PowerShell). Or clink. Or yori. This would make a super interesting blog post (which you could point people to any time they ask this again) -- maybe ping Raymond Chen? :D

claunia commented

@doctorpangloss commented on GitHub (Oct 28, 2023):

I use https://frippery.org/busybox/

It's literally burned us 100% of the times we've tried to touch it.

Would it be possible to release the source of cmd.exe? Is it even that sensitive? Lemme pitch the metric: "Number of cmd.exes open sourced." An increase in this metric from 0 to 1, it's +infinity percent!

I got you, thanks for the kind note.

@doctorpangloss commented on GitHub (Oct 28, 2023): I use https://frippery.org/busybox/ > It's literally burned us 100% of the times we've tried to touch it. Would it be possible to release the source of `cmd.exe`? Is it even that sensitive? Lemme pitch the metric: "Number of cmd.exes open sourced." An increase in this metric from 0 to 1, it's +infinity percent! I got you, thanks for the kind note.

claunia commented

@noseratio commented on GitHub (Oct 28, 2023):

You're heard, for sure. But we're not planning on touching cmd.exe. Literally last week we had a P0 fire where we broke the core Windows build because we tried making what seemed like a trivial internal change to the CMD.exe code. It's literally burned us 100% of the times we've tried to touch it.

If you want a modern, updated shell on Windows, you should try out PowerShell 7. Or clink. Or yori.

Sadly, many popular CLI/DevOps tools (Node.js, NPM, Chromium build, etc) already use CMD on Windows, and that's not gonna change, they won't switch to PowerShell.

The fear of changing CMD to actually terminate upon Ctrl+C is not only irrational, but also dangerous.

E.g., like I mentioned previously in this thread, the following will delete all .gif files, when I franticly press Ctrl+C two times while trying to stop it. It's just beyond my comprehension.

@echo off
echo About to delete *.gif. 
pause
del /q *.gif

At least, it it possible to make the second Ctrl+C act as Y when CMD is already asking Terminate batch job (Y/N)? ❓

What do you think about that, @zadjii-msft?

@noseratio commented on GitHub (Oct 28, 2023): > You're heard, for sure. But we're not planning on touching `cmd.exe`. Literally _last week_ we had a P0 fire where we broke the core Windows build because we tried making what seemed like a trivial internal change to the CMD.exe code. It's literally burned us 100% of the times we've tried to touch it. > > If you want a modern, updated shell on Windows, you should try out [PowerShell 7](https://github.com/PowerShell/PowerShell). Or clink. Or yori. Sadly, many popular CLI/DevOps tools (Node.js, NPM, Chromium build, etc) already use CMD on Windows, and that's not gonna change, they won't switch to PowerShell. The fear of changing CMD to actually terminate upon Ctrl+C is not only irrational, but also dangerous. E.g., like I mentioned [previously](#issuecomment-939650941) in this thread, the following will delete all .gif files, when I franticly press Ctrl+C two times while trying to stop it. It's just beyond my comprehension. ```batch @echo off echo About to delete *.gif. pause del /q *.gif ``` At least, it it possible to make the second Ctrl+C act as `Y` when CMD is already asking `Terminate batch job (Y/N)?` ❓ What do you think about that, @zadjii-msft?

claunia commented

@skissane commented on GitHub (Mar 12, 2024):

I understand why you are terrified of changing anything in cmd.exe.

But:

Define a brand new registry value (or even a whole new key) which nobody is using–if you are truly paranoid about the chance someone already has it set, put it somewhere unrelated to the registry keys cmd.exe already looks at, even put a random GUID in the key or value name so the chance that it already exists is astronomically low
At cmd.exe startup, check if that registry value exists and has the value 1, and if so set an internal boolean flag
If the boolean flag is set, skip displaying the Terminate batch job (Y/N)? prompt, act as if Y was answered. This is likely just one extra if statement (if that)

That way, people who want to make this prompt go away, can create the new registry key/value.

It is rather difficult to conceive of a way in which the above change could possibly break anything. If the registry key/value isn't set, it behaves identically to at present. If setting it breaks something, the solution is to remove that registry setting.

@skissane commented on GitHub (Mar 12, 2024): I understand why you are terrified of changing anything in `cmd.exe`. But: 1. Define a *brand new* registry value (or even a whole new key) which nobody is using–if you are truly paranoid about the chance someone already has it set, put it somewhere unrelated to the registry keys `cmd.exe` already looks at, even put a random GUID in the key or value name so the chance that it already exists is astronomically low 2. At `cmd.exe` startup, check if that registry value exists and has the value `1`, and if so set an internal boolean flag 3. If the boolean flag is set, skip displaying the `Terminate batch job (Y/N)?` prompt, act as if `Y` was answered. This is likely just one extra `if` statement (if that) That way, people who want to make this prompt go away, can create the new registry key/value. It is rather difficult to conceive of a way in which the above change could possibly break anything. If the registry key/value isn't set, it behaves identically to at present. If setting it breaks something, the solution is to remove that registry setting.

claunia commented

@andry81 commented on GitHub (Mar 13, 2024):

@skissane

Define a brand new registry value

Bad idea. It will affect all cmd.exe instances. Better, for example, to extend setlocal with a new flag like:
setlocal DISABLECTRLBREAKINTERACTION

@andry81 commented on GitHub (Mar 13, 2024): @skissane > 1. Define a _brand new_ registry value Bad idea. It will affect all cmd.exe instances. Better, for example, to extend `setlocal` with a new flag like: `setlocal DISABLECTRLBREAKINTERACTION`

claunia commented