我在 Windows 中使用 git bash 来运行一些 nodejs 脚本，但是每当我使用它并退出时，git bash 会自动将该进程转移到后台并且不允许我使用该端口，除非我使用命令终止该端口。

但是当我使用 cmd 时，它工作得很好，进程不会在后台运行，也不需要终止在端口上运行的进程，为什么？

最佳答案

vscode issue 24452 中也有报道导致 node-pty issue 7 .

均引用git-for-windows/git issue 227

官方维护者Johannes Schindelin (dscho) 3 个月前(2017 年 6 月)提到:

Alas, it is not. In v2.13.1, I changed the way Ctrl+C works and the problem described in this ticket still persists.

Any help would be very much appreciated.

ConEmu/issue 402包括:

The problem comes from different implementations of Ctrl+C processing in cygwin/msys applications.
POSIX applications are ready to process "signals" in most cases, but often ignores console events.

2018 年 4 月更新，Johanes just added :

After testing this with my fix for #1491 (which will hit https://wingit.blob.core.windows.net/files/index.html soon, so you can verify my claim, and you should, if you are interested in this issue) it would appear that there is no longer a freeze (although quite a bit of delay if you hit Ctrl+C tons of times).

参见 git-for-windows/MSYS2-packages commit f4fda0f :

msys2-runtime: revamp Ctrl+C handling yet again

This thing again...

Background: when you hit Ctrl+C on Linux or macOS, a signal (SIGINT) is sent to the foreground process and its child processes. This signal can be intercepted by installing a signal handler for this specific signal.
On Windows, there is no precise equivalent for this system.

Instead, the Ctrl+C is translated by the current ConHost (i.e. the container running the Console processes) to a ConsoleCtrl event that is sent to all processes attached to that Console. If any of these processes installed a handler via SetConsoleCtrlHandler(), they can intercept that event (and avoid exiting or doing some cleanup work).

On Linux and macOS (and every Unix flavor, really), processes can also be killed via the kill executable, which really just sends a signal to the process, typically SIGTERM. Processes can intercept that signal, too. To force processes to terminate, without giving them any chance to prevent that, SIGKILL can be sent.
There is no equivalent for SIGTERM on Windows. To emulate SIGKILL on Windows, TerminateProcess() can be used, but it only kills one process (unlike SIGKILL, which is sent also to the child processes).

In Git for Windows, we struggled with emulating SIGINT, SIGTERM and SIGKILL handling essentially since the beginning of the efforts to port Git to Windows.

评论的其余部分描述了最初的尝试和新的尝试。

这可能会进入 Git 2.18(2018 年第二季度)。

Windows 版 Git 后台作业的另一个原因:新命令 git maintenance (Git 2.29(2020 年第四季度))。

但这随着 Git 2.31(2021 年第一季度)的推出而改变，并且引入了计划维护任务以支持其 native 计划方法不是“cron”的平台。

参见 commit 3797a0a , commit 2afe7e3 (2021 年 1 月 5 日)和 commit 16c5690 , commit 31345d5 (2020 年 11 月 24 日)Derrick Stolee ( derrickstolee ) .
^{(由 Junio C Hamano -- gitster -- merge 于 commit b2ace18 ，2021 年 1 月 15 日)}

maintenance: use Windows scheduled tasks

^{Co-authored-by: Eric Sunshine
Signed-off-by: Eric Sunshine
Signed-off-by: Derrick Stolee}

Git's background maintenance uses cron by default, but this is not available on Windows.
Instead, integrate with Task Scheduler.

Tasks can be scheduled using the 'schtasks' command.
There are several command-line options that can allow for some advanced scheduling, but unfortunately these seem to all require authenticating using a password.

Instead, use the "/xml" option to pass an XML file that contains the configuration for the necessary schedule.
These XML files are based on some that I exported after constructing a schedule in the Task Scheduler GUI.
These options only run background maintenance when the user is logged in, and more fields are populated with the current username and SID at run-time by 'schtasks'.

Since the GIT_TEST_MAINT_SCHEDULER environment variable allows us to specify 'schtasks' as the scheduler, we can test the Windows-specific logic on other platforms.
Thus, add a check that the XML file written by Git is valid when xmllint exists on the system.

Since we use a temporary file for the XML files sent to 'schtasks', we prefix the random characters with the frequency so it is easier to examine the proper file during tests.
Instead of an exact match on the 'args' file, we 'grep' for the arguments other than the filename.

There is a deficiency in the current design.
Windows has two kinds of applications: GUI applications that start by "winmain()" and console applications that start by "main()".
Console applications are attached to a new Console window if they are not already associated with a GUI application.
This means that every hour the scheduled task launches a command window for the scheduled tasks.
Not only is this visually obtrusive, but it also takes focus from whatever else the user is doing!

A simple fix would be to insert a GUI application that acts as a shim between the scheduled task and Git.
This is currently possible in Git for Windows by setting the <Command> tag equal to

C:\Program Files\Git\git-bash.exe

with options "--hide --no-needs-console --command=cmd\git.exe", followed by the arguments currently used.
Since git-bash.exe is not included in Windows builds of core Git, I chose to leave out this feature.
My plan is to submit a small patch to Git for Windows that converts the use of git.exe with this use of git-bash.exe in the short term.
In the long term, we can consider creating this GUI shim application within core Git, perhaps in contrib/.

git maintenance现在包含在其 man page 中:

BACKGROUND MAINTENANCE ON WINDOWS SYSTEMS

Windows does not support cron and instead has its own system for scheduling background tasks. The git maintenance start command uses the schtasks command to submit tasks to this system. You can inspect all background tasks using the Task Scheduler application. The tasks added by Git have names of the form Git Maintenance (<frequency>). The Task Scheduler GUI has ways to inspect these tasks, but you can also export the tasks to XML files and view the details there.

Note that since Git is a console application, these background tasks create a console window visible to the current user. This can be changed manually by selecting the "Run whether user is logged in or not" option in Task Scheduler. This change requires a password input, which is why git maintenance start does not select it by default.

If you want to customize the background tasks, please rename the tasks so future calls to git maintenance (start|stop) do not overwrite your custom tasks.

关于windows - 为什么安装在 windows 中的 git bash 在后台运行脚本？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/46512056/