How can I suppress “Terminate batch job (Y/N)” confirmation in PowerShell?

As the other answer notes, the correct fix is to replace cmd scripts with ps1 versions.

However another workaround for users of the Hyper shell is 'Hyper yes', a plugin that automatically hits y for you when the prompt comes up.

The behavior is neither caused by PowerShell nor can PowerShell change it (as evidenced by the PowerShell source-code repo not containing the prompt message).

The behavior is built into cmd.exe - Powershell, in this case, is calling a .cmd file (batch file), which is interpreted by cmd.exe.

• If you explicitly control the invocation of the target executable, you can fix this by moving to Powershell - note this has its own considerations, see below.

• If you do not explicitly control the invocation of the target executable, you're out of luck (unless you're willing to install third-party cmd.exe replacements) and must press Ctrl+C twice in order to terminate execution.

• A[n ill-advised] workaround is to modify the cmd.exe binary - see article with instructions on how to patch the cmd.exe executable in order to suppress the prompt. Additionally, you can post a feature request on GitHub to request that this behavior be fixed at the source, though that is unlikely to happen for reasons of backward compatbility.

To demonstrate the behavior:

The examples assume that Node.js is installed and that node.exe is therefore in your PATH:

First, invoke node.exe directly, with a tight loop that requires you to press Ctrl+C to terminate the process.

PS> node -e "while (true);"

As you'll see, pressing Ctrl+C instantly terminates the process - no confirmation prompt.

Now, let's create a sample batch file that invokes the same command and invoke that batch file:

PS> "@echo off`nnode -e `"while (true);`"" | Set-Content test.cmd
PS> ./test.cmd

As you'll see, pressing Ctrl+C now presents the undesired Terminate batch job (Y/N)? prompt. (You'd get the same behavior if you ran the batch file from cmd.exe.)

To demonstrate that gulp is a cmd file:

You say you're running your command via gulp's CLI.

On Windows, the entry point for the gulp CLI is gulp.cmd [see update in the bottom section] - i.e., a batch file. That is how it works in general for npm-package "binaries" (executables) implemented as either JS files or shell scripts.

That gulp invokes gulp.cmd can be verified as follows:

# Execute from a project folder that has `gulp` installed as a dependency.
# If `gulp` is installed *globally* 
# Note: CLI `npx` requires npm version 5.2.0+
PS C:\some\NodeJs\project> npx where gulp

You'll see something like:

C:\some\NodeJs\project\node_modules\.bin\gulp
C:\some\NodeJs\project\node_modules\.bin\gulp.cmd

Note that where.exe also lists the extension-less Unix-shell script, ...\gulp; however, from cmd.exe / Powershell such a shell script isn't directly executable, and it is ...\gulp.cmd - the batch file - that is executed.
(If in doubt, place a command such as @set /p dummy="Press a key" at the start of the gulp.cmd file, and you'll see that this command executes when you invoke gulp without the .cmd extension.
Also note that there is no gulp.exe.)

More generally, on Windows, a project's node_modules\.bin subfolder contains pairs of CLI entry points for the CLIs that come with packages that the project depends on locally:

• node_modules\.bin\<some-cli> is the Unix shell script (whose executing interpreter is controlled via its shebang line).
• node_modules\.bin\<some-cli>.cmd is the helper batch file for Windows.

---

Updates and future considerations:

In the context of npm modules, the problem would go away if a PowerShell script (*.ps1) were used as the helper script on Windows. There are tickets for npm, yarn and similar software to do this. There are also some drawbacks:

• *.ps1 files aren't directly executable from outside of PowerShell, notably from cmd.exe and File Explorer (and changing that is nontrivial).

• PowerShell still hasn't fully replaced cmd.exe as the default shell, as of Windows 10 (and won't anytime soon, if ever).

When called from PowerShell, a *.ps1 file would be found and run in-process, so a possible solution is for the npm project to also provide *.ps1 helper scripts, which would take precedence over *.cmd files of the same name.

• Update:
  • Recent versions of npm (verified in 6.14.10) indeed DO install such *.ps1 files.
  • Alternative package manager yarn, since v2 does not seem to use batch files anymore at all, so the original problem is bypassed there; (v1, by contrast, still uses batch files (only); upgrading from v1 must be done on a per-project basis see the migration instructions).