bash - 为什么我不能在 bash 脚本中使用作业控制？

Question

在this answer到另一个question , 有人告诉我

in scripts you don't have job control (and trying to turn it on is stupid)

这是我第一次听到这个，我仔细研究了 bash.info 中关于作业控制的部分(第 7 章)，发现没有提到这两个断言。 [更新:手册页稍微好一点，提到了“典型”使用、默认设置和终端 I/O，但没有真正的理由说明作业控制对于脚本来说特别不明智。]

那么为什么基于脚本的作业控制不起作用，是什么让它成为一种不好的做法(又名“愚蠢”)？

编辑: 有问题的脚本启动一个后台进程，启动第二个后台进程，然后尝试将第一个进程放回前台，以便它具有正常的终端 I/O(好像直接运行)，然后可以从脚本外部重定向。不能对后台进程执行此操作。

如 accepted answer 所述对于另一个问题，存在其他脚本可以在不尝试作业控制的情况下解决该特定问题。美好的。被抨击的脚本使用了硬编码的工作编号——显然很糟糕。但我试图了解工作控制是否是一种从根本上注定要失败的方法。它似乎仍然可以工作...

Answer 1

他的意思是作业控制在非交互模式下默认关闭(即在脚本中。)

来自 bash 手册页:

JOB CONTROL
       Job  control refers to the ability to selectively stop (suspend)
       the execution of processes and continue (resume) their execution at a
       later point.
       A user typically employs this facility via an interactive interface
       supplied jointly by the system’s terminal driver and bash.

和

   set [--abefhkmnptuvxBCHP] [-o option] [arg ...]
      ...
      -m      Monitor mode.  Job control is enabled.  This option is on by
              default for interactive shells on systems that support it (see
              JOB CONTROL above).  Background processes run in a separate
              process group and a line containing their exit status  is
              printed  upon  their completion.

当他说“愚蠢”时，他的意思不仅是:

1. 作业控制意味着主要是为了促进交互式控制(而脚本可以直接与 pid 一起工作)，但也是
2. 我引用他的原始答案，... 依赖于您之前没有在脚本中开始任何其他工作这一事实，这是一个错误的假设。这是非常正确的。

更新

在回答您的评论时:是的，没有人会阻止您在 bash 脚本中使用作业控制——强制禁用 没有硬性案例 set -m (也就是说，是的，如果您愿意，脚本中的作业控制将起作用。)请记住，最后，尤其是在脚本中，给猫剥皮的方法总是不止一种，但有些方法更便携、更可靠，使处理错误情况、解析输出等变得更简单。

您的特定情况可能会或可能不会保证采用不同于 lhunath(和其他用户)认为的“最佳实践”的方式。