jobs 只显示当前 shell 启动且未被 nohup/disown/子 shell 隔离的作业；fg/bg 必须用 %1 等格式，不可省略 %；ctrl+z 无效时需检查进程实际状态；长期后台运行应使用 nohup 或 disown。
当前终端里跑着哪些任务，只用 jobs 就能看清，不需要 ps 或 top ——但前提是这些进程得是本 shell 启动的、没被 nohup 或 disown 过的。
为什么 jobs 查不到你认为“在后台”的进程
常见错误现象：运行了 sleep 100 &，再敲 jobs 却没显示；或者用另一个终端 ps aux | grep sleep 能看到，但本终端 jobs 空空如也。
这是因为：jobs 只管当前 shell 会话中由它自己 fork 出来的作业（job），不跨会话、不跨 shell 层级。以下情况会导致 jobs 不可见：
- 进程是用
nohup sleep 100 &启动的 → 已脱离当前 job 控制表 - 进程是在子 shell 里启动的，比如
(sleep 100 &)→ 父 shell 不记录该 job - 进程启动后执行过
disown %1→ 主动从 job 表中移除 - 你换了个终端登录，或用了
ssh新连接 → 作业只属于原 shell 实例
fg 和 bg 的参数到底怎么写才有效
很多人输 fg 1 报错：bash: fg: 1: no such job。问题出在语法上——fg 和 bg 必须带 % 前缀，不能直接跟数字。
正确写法和含义：
-
fg（无参数）→ 恢复标有+的那个作业（即最近一次挂起/启动的） -
fg %1→ 恢复作业号为 1 的任务（注意是%1，不是1） -
fg %vim→ 恢复命令名以vim开头的作业（支持前缀匹配，但必须唯一） -
bg %2→ 把已停止的作业 2 放入后台继续运行
如果输错成 fg 1，shell 会把它当做一个叫 1 的命令去执行，自然失败。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
Ctrl+Z 挂起后，bg 不工作？检查进程状态是否真是 Stopped
按下 Ctrl+Z 后，你以为进程停了，但 jobs 显示却是 Running，这时 bg %1 会报错或无效。
原因通常是：该进程收到 SIGTSTP 后没真正停止，而是忽略了信号（比如某些用 C 写的 daemon、或设置了 signal(SIGTSTP, SIG_IGN) 的程序）。验证方法：
- 执行
jobs -l，看 PID 列是否存在；若存在，再用kill -0 PID测试进程是否存活 - 用
ps -o pid,stat,comm -p PID查状态字段：T表示 stopped，R或S表示仍在运行 - 若确实是
R状态，说明Ctrl+Z失效，此时只能kill %1终止，或改用kill -STOP PID强制挂起
想让进程真·长期后台运行？别只靠 bg
bg 让进程在后台跑，但它仍和终端绑定：一旦你关掉这个 shell，进程大概率收到 SIGHUP 被杀掉（除非程序自己处理了该信号）。
真正可靠的做法只有两个：
- 启动时就加
nohup command &→ 忽略SIGHUP，输出默认重定向到nohup.out - 先
Ctrl+Z→bg %1→ 立即执行disown %1→ 彻底剥离与终端关系
注意：disown 后，该作业就从 jobs 列表消失，也无法再用 fg/bg 控制——这是设计使然，不是 bug。
