Git Bash Integration in VSCode and Windows Terminal Not Handling Close Commands Correctly

[Okeanos]

Windows Terminal and Visual Studio Code (VSCode) use the /bin/bash.exe to start a Git Bash session inside the console windows (1, 2).

Personally, I already noted that VSCode uses only the --login (-l) argument to start the session as opposed to -li (--login -i) that we introduced in the Windows Terminal profile to start an actual interactive login session. That obviously has some very particular side effects; more on that later.

Now, back to the topic at hand: Git Bash Integration in VSCode and Windows Terminal do not handle being closed correctly. That is, unless exit (Ctrl+D) is used to manually terminate the session. On the other hand, a regular Git Bash session started using git-bash.exe works as expected if the MinTTY terminal option is selected, obviously.

What does "works as expected" mean? I already noted that the Windows Terminal integration is started as an interactive shell and that this has side effects:

Straight from the Bash manual pages some excerpts:

SIGNALS
When bash is interactive, in the absence of any traps, it ignores SIGTERM (so that kill 0 does not kill an interactive shell), and SIGINT is caught and handled (so that the wait builtin is interruptible).

HISTORY EXPANSION
Non-interactive shells do not perform history expansion by default

SHELL BUILTIN COMMANDS
set -o option-name
history Enable command history, as described above under HISTORY. This option is on by default in interactive shells.

This should explain why the VSCode managed bash suffers from … let's call it long term memory loss, right? Details to be found in 3, 4, 5, 6. In effect not starting bash as an interactive session (the way VSCode does it) will bash skip the history stuff, so using -i as start up parameter as we do for Windows Terminal should fix this, right?

The answer to that is: no (see also 7, 8). Neither changing the start up parameters in VSCode nor using the default Git Bash Terminal integration will trigger Bash to write (to) a .bash_history file unless exit (Ctrl+D) is used manually. I am trying to understand why because git-bash.exe does trigger creation/write to this file and apparently (?) there were some fixes in the underlying components such as Cygwin/MinTTY concerning the new Windows Console APIs. There also is something called winpty that can do signal conversion between Windows and cygwin/mintty? This Stackoverflow thread links some possibly related details as well.

This behavious is reproducible with both of these Git Installation options using the latest release of Git for Windows, current stable Terminal (1.15.2874.0) and stable VSCode (1.72.2). Additionally the ConHost version doesn't handle closing a bash correctly "on its own" either.

Editor Option: VIM
Custom Editor Path: 
Default Branch Option:  
Path Option: Cmd
SSH Option: OpenSSH
Tortoise Option: false
CURL Option: WinSSL
CRLF Option: CRLFCommitAsIs
Bash Terminal Option: MinTTY
Git Pull Behavior Option: Merge
Use Credential Manager: Enabled
Performance Tweaks FSCache: Enabled
Enable Symlinks: Disabled
Enable Pseudo Console Support: Disabled
Enable FSMonitor: Disabled

Editor Option: VIM
Custom Editor Path: 
Default Branch Option:  
Path Option: Cmd
SSH Option: OpenSSH
Tortoise Option: false
CURL Option: WinSSL
CRLF Option: CRLFCommitAsIs
Bash Terminal Option: ConHost
Git Pull Behavior Option: Merge
Use Credential Manager: Enabled
Performance Tweaks FSCache: Enabled
Enable Symlinks: Disabled
Enable Pseudo Console Support: Disabled
Enable FSMonitor: Disabled

Adding the the pseudo console support option during installation also has no effect on this behaviour:

Editor Option: VIM
Custom Editor Path: 
Default Branch Option:  
Path Option: Cmd
SSH Option: OpenSSH
Tortoise Option: false
CURL Option: WinSSL
CRLF Option: CRLFCommitAsIs
Bash Terminal Option: MinTTY
Git Pull Behavior Option: Merge
Use Credential Manager: Enabled
Performance Tweaks FSCache: Enabled
Enable Symlinks: Disabled
Enable Pseudo Console Support: Enabled
Enable FSMonitor: Disabled

Now back on track: what does the MinTTY version do within git-bash.exe that doesn't happen in bash.exe itself when it comes to handling close-signals originating from Windows? Can support for these close signals be added to bash.exe? Where would that issue have to be raised? Am I overlooking something (really simple)?

Oh yes, there is a workaround:

export PROMPT_COMMAND="history -a"

This is also usually used to ensure that multiple parallel bash instances (even on Linux and macOS) write to the same history file. But that shouldn't be necessary for single instance windows of bash. I want a better solution for that!