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

在 this answer到另一个 question，我被告知

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

这是我第一次听到这个，我已经在工作控制(第7章)的bash.info部分，找到没有提到任何一个断言。 [更新：手册页有点更好，提到’典型’使用，默认设置和终端I / O，但没有真正的原因为什么作业控制是特别不明智的脚本。

那么，为什么不基于脚本的作业控制工作，什么使它成为一个坏的做法(又名“愚蠢”)？

编辑：有问题的脚本启动后台进程，启动第二个后台进程，然后尝试将第一个进程放回前台，使其具有正常的终端I / O(如果直接运行)，然后可以重定向外面的脚本。不能做到后台进程。

正如accepted answer到另一个问题所指出的，存在其他脚本来解决这个特定的问题，而不尝试作业控制。精细。而lambasted脚本使用硬编码的工作号码 – 显然不好。但我想了解工作控制是否是一个根本注定的方法。它仍然似乎也许它可以工作…

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

从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.

当他说“很蠢”时，他的意思不仅是：

>是作业控制，主要用于促进交互式控制(而脚本可以直接与pid的工作)，但也
>我引用他的原始答案，…依赖于你没有开始任何其他工作以前在脚本中这是一个坏的假设。这是相当正确的。

更新

在回答你的评论：是的，没有人会阻止你使用作业控制在你的bash脚本 – 没有硬的情况下强制禁用set -m(即是，从脚本的作业控制将工作，如果你想它。 )记住，最后，特别是在脚本中，总是有不止一种方法来皮肤一只猫，但一些方法更便携，更可靠，使处理错误情况，解析输出更简单等。

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