🙏🏻 [feat/req] suppress annoying "Terminate batch job (Y/N)?" for shimmed deno scripts (Windows)

[rivy]

At least up to Deno 1.8.1, any shimmed Deno script under Windows will prompt with "Terminate batch job (Y/N)?" when terminated with a CTRL-C interrupt. I suggest that deno install ... create a BAT/CMD file with the construction @goto #_undefined_# 2>NUL || @title %COMSPEC% & @deno .... This exploits a known CMD quirk:

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)

@goto #_undefined_# 2>NUL terminates the BAT/CMD script but only after executing the rest of the currently parsed code block. This executes the @deno ... portion in command line context (instead of batch context), so that there is no batch script to terminate. And so, the "Terminate batch job (Y/N)?" prompt is avoided.

Notably, this construction also protects against a possible future problem related to a CMD shell bug. Exiting a batch script via fall-thru, exit ERROLEVEL, or exit /B ERRORLEVEL does NOT return ERRORLEVEL as the process exit code unless the BAT/CMD file is executed with a call BAT_FILE command. The ERRORLEVEL is set and returned to the parent shell correctly, but the process exit code is not. There's more detail, some references, and an alternate solution in my commit for pl2bat, which is a similar command wrapper for perl.

It's a "possible future problem" because the current shim takes advantage of another countervailing CMD quirk which does pass the ERRORLEVEL out as the process exit code if and only if the command executing the target executable is the last command in the last parsable unit of the BAT/CMD file. If the shim is ever changed to have another code parse unit after the @deno ... execution line, then the process exit code will not be set correctly unless the shim is called using call SHIM_NAME, which cannot be expected.

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.

yarn has adopted this construction.

[1] MSFT terminal ~ Disable "Terminate batch job (Y/N)?" discussion

[rivy]

npm also adopted the construction for their cmd-shim.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

[rivy]

Not stale

[rivy]

@ry , if you're interested, I've prototyped an enhanced shim that fixes (or works around) this, #9871, and #9874.

The shim avoids the "Terminate batch job (Y/N)?" prompt but still leaves a pair of CTRL-C characters displayed when interrupting the shim (not perfect but much less annoying). Likely, this can be fixed if signal handlers are implemented for Windows (see #9995). This is automatic for any Windows script installed with the shim enhancement.

If you want to look at the shim, you can install a CLI application with dxi (from dxx) which will install a TARGET with the enhanced shim. Better command line support (better command line quoting, bash-equivalent expansion and globbing, ...) is available as opt-in.

args shows the possibilities.

deno install -A https://deno.land/x/dxx@v0.0.4/src/dxi.ts
dxi -A https://deno.land/x/dxx@v0.0.4/eg/args.ts