When I press Ctrl+C in PowerShell, I receive:
Terminate batch job (Y/N)?
Similar to https://superuser.com/questions/35698/how-to-supress-terminate-batch-job-y-n-confirmation, except for Windows PowerShell.
Does PowerShell provide any more control over batch jobs than what CMD does?
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.
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
.)
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.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.
npm
(verified in 6.14.10) indeed DO install such *.ps1
files.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).