无法 fg 包含 less 的 zsh 函数

这是影响 zsh 5.9 的一个错误。它已于 2022 年 11 月修复，但自 2024 年 12 月以来尚未发布任何版本。

如果你这样做：

$ find . | less
^Z
zsh: suspended  find . | less
$ ps -Ho pid,ppid,pgid,tpgid,args
    PID    PPID    PGID   TPGID COMMAND
  11094    5260   11094   11150 /bin/zsh
  11128   11094   11128   11150   find .
  11129   11094   11128   11150   less
  11150   11094   11150   11150   ps -Ho pid,ppid,pgid,tpgid,args
$ jobs -p
[1]  + 11128 suspended  find . |
             suspended  less

find11128 确实是具有和 的作业的 PGID less，并且恢复工作正常，但是：

$ f() {find . -type f | less}
$ f
zsh: suspended  find . -type f |
$ ps -Ho pid,ppid,pgid,tpgid,args
    PID    PPID    PGID   TPGID COMMAND
  11094    5260   11094   11520 /bin/zsh
  11492   11094   11492   11520   find . -type f
  11493   11094   11492   11520   less
  11501   11094   11501   11520   /bin/zsh
  11520   11094   11520   11520   ps -Ho pid,ppid,pgid,tpgid,args
$ jobs -p
[1]  + 11493 suspended  find . -type f |
             suspended

这次，11493 是 的 PID ，而不是同时具有和 的less作业的 PGID ，后者是 11492。findless

因此，当fg尝试将作业放在前台时，它会执行一个tcsetpgrp(11493)无法将该作业放在前台的操作，然后继续使用 SIGCONT 恢复所有进程，并且碰巧less在恢复时执行了一个后台进程不允许执行的操作tcsetattr()（该命令stty通常执行的操作），因此整个进程组都会收到 SIGTTOU 信号并再次被暂停。

此处的一个解决方法是将函数定义更改为：

f() (find . | less)

也就是说，使用子 shell 而不是命令组作为函数主体，这样父进程只需要关心一个进程，不会造成混淆。

使用：

f() {less < <(find .)}

似乎也有效（尽管由于某种原因意味着额外的过程）。

作业控制是相当棘手的事情，特别是当像 zsh 或 ksh 那样，您尝试在当前 shell 中运行管道的右侧，以及像 zsh 或 AT&T ksh 那样，您尝试在复合命令中按下 ^Z 时获得更有用的行为（例如f此处的函数主体）。

请注意，暂停时上面出现的额外 11501 进程f。它在那里，以便函数的其余部分可以在find、less恢复（使用fg或bg）后恢复并最终终止。

看看在 bash 或 mksh 中如何操作：

f() { sleep 100; echo here; }
f

然后点击 ^Z，sleep程序会暂停，但此时echo here会运行！然后如果你，程序会恢复运行，但其余函数已经执行完毕！fgsleep

请参阅代码中解释它的注释：

/*
 * Job control in zsh
 * ==================
 *
 * A 'job' represents a pipeline; see the section JOBS in zshmisc(1)) for an
 * introduction.  The 'struct job's are allocated in the array 'jobtab' which
 * has 'jobtabsize' elements.  The job whose processes we are currently
 * preparing to execute is identified by the global variable 'thisjob'.
 *
 * A 'superjob' is a job that represents a complex shell construct that has been
 * backgrounded.  For example, if one runs '() { vi; echo }', a job is created
 * for the pipeline 'vi'.  If one then backgrounds vi (with ^Z / SIGTSTP),
 * the shell forks; the parent shell returns to the interactive prompt and
 * the child shell becomes a new job in the parent shell.  The job representing
 * the child shell to the parent shell is a superjob (STAT_SUPERJOB); the 'vi'
 * job is marked as a subjob (STAT_SUBJOB) in the parent shell.  When the child
 * shell is resumed (with fg / SIGCONT), it forwards the signal to vi and,
 * after vi exits, continues executing the remainder of the function.
 * (See workers/43565.)
 */

其中一个问题（我不知道它与这里讨论的问题有多少关系；编辑，可能没有考虑修复）是“超级作业”不是已暂停进程的父级，因此例如无法获取它们的退出状态：

$ { (sleep 4; exit 4); echo "$?"; }
^Zzsh: suspended  ( sleep 4; exit 4; )
$ fg
[1]  + continued  ( sleep 4; exit 4; )
148
$

echo "$?"确实是在(sleep...)终止后运行，而不是像在中那样在暂停时运行bash，但$?反映了暂停状态，而不是4您所期望的。

zshmisc(1)正如上面的评论所暗示的那样，您可以找到或中描述的行为info zsh jobs：

请注意，如果在前台运行的作业是 shell 函数，则暂停它将导致 shell 分叉。这是将函数的状态与执行作业控制的父 shell 的状态分开所必需的，以便后者可以返回到命令行提示符。因此，即使使用 fg 继续作业，该函数也将不再是父 shell 的一部分，并且该函数设置的任何变量在父 shell 中都不可见。因此，行为与从未暂停函数的情况不同。在这方面，Zsh 与许多其他 shell 不同。

另一个副作用是，使用 disown 来暂停 shell 代码创建的作业时会延迟：只有当从父 shell 启动的任何进程终止后，才能放弃该作业。此时，放弃的作业会从作业列表中悄无声息地消失。

当 shell 执行管道右侧的代码或任何复杂的 shell 结构（如 if、for 等）时，也会发现相同的行为，以便将整个代码块作为单个作业进行管理。后台作业通常允许产生输出，但可以通过给出命令“stty tostop”来禁用它。如果您设置此 tty 选项，则后台作业在尝试产生输出时将暂停，就像它们尝试读取输入时一样。

当命令被暂停并在稍后使用内置命令 fg 或 wait 继续时，zsh 将恢复暂停时有效的 tty 模式。如果命令通过 'kill -CONT' 继续，则此操作（有意）不适用，如果命令通过 bg 继续，则不适用。