我猜你遇到的问题应该是：直接在Git Bash里敲这些命令时，后台进程能被jobs命令查到，也能用kill正常管理，但通过./abc.sh运行脚本后，这些进程不在当前shell的jobs列表里，甚至脚本退出后进程也跟着终止了？别急，这是shell脚本运行的常见问题，咱们一步步解决：

问题根源 #

当你在Git Bash交互式环境中直接执行命令时，后台进程属于当前的交互式shell，所以jobs能追踪到它们的状态。但运行shell脚本时，默认会启动一个非交互式的子shell来执行脚本内容，脚本里的后台进程属于这个子shell，而不是你当前操作的主shell。当脚本执行完毕，子shell会退出，这些后台进程可能会被系统发送的SIGHUP信号终止；就算侥幸存活，你在主shell里用jobs也看不到它们的踪迹。

解决方案 #

方案1：让脚本在当前shell中执行（最贴合你直接敲命令的需求） #

不要用./abc.sh运行脚本，而是用source命令（或者简写.）让脚本在当前shell环境中执行：

source abc.sh
# 或者更简洁的写法
. abc.sh

这样脚本里的所有命令都会直接在你当前的Git Bash shell中运行，后台进程也会被jobs命令追踪到，和你手动敲命令的效果完全一致。

方案2：让进程脱离子shell独立运行（适合不需要jobs追踪，只想让进程持续跑的场景） #

如果只是想让进程在后台持续运行，不管脚本是否退出，可以给命令加上nohup，同时完善目录切换的判断（避免目录切换失败时在错误路径运行命令）：

#!/bin/bash
cd "<target_dir1>" && nohup <my_command1> &>> output.log &
cd "<target_dir2>" && nohup <my_command2> &>> output.log &

运行脚本后，就算脚本执行完毕退出，进程也会继续运行。你可以通过ps aux | grep <my_command1>查找进程ID，再用kill [进程ID]来终止进程。

方案3：保存进程ID到文件，手动管理（进阶灵活方案） #

如果你坚持要通过./abc.sh运行脚本，又想方便管理进程，可以在脚本里把每个后台进程的PID（进程ID）保存到文件中：

#!/bin/bash
cd "<target_dir1>" && <my_command1> &>> output.log &
echo $! > pid1.txt
cd "<target_dir2>" && <my_command2> &>> output.log &
echo $! > pid2.txt

$!是shell内置变量，表示上一个后台进程的PID。之后你可以通过cat pid1.txt查看进程ID，用kill $(cat pid1.txt)来终止对应进程。

额外小提示 #

• 记得给脚本加上执行权限：chmod +x abc.sh，这样后续运行会更顺畅。
• 如果你的<my_command1>是依赖终端交互的程序，在后台启动后可以加上disown %1（%1是第一个后台任务的编号），避免子shell退出时发送终止信号。

内容的提问来源于stack exchange，提问作者Vivek Gupta