title: Why can't I use job control in a bash script?
body: <p>In <a href="https://stackoverflow.com/questions/687948#688836">this answer</a> to another <a href="https://stackoverflow.com/questions/687948">question</a>, I was told that</p>
  
  <blockquote>
    <p>in scripts you don't have job control
    (and trying to turn it on is stupid)</p>
  </blockquote>
  
  <p>This is the first time I've heard this, and I've pored over the bash.info section on Job Control (chapter 7), finding no mention of either of these assertions. [<strong>Update:</strong> The man page is a little better, mentioning 'typical' use, default settings, and terminal I/O, but no real reason why job control is particularly ill-advised for scripts.]</p>
  
  <p>So why doesn't script-based job-control work, and what makes it a bad practice (aka 'stupid')?</p>
  
  <p><strong>Edit:</strong> The script in question starts a background process, starts a second background process, then attempts to put the first process back into the foreground so that it has normal terminal I/O (as if run directly), which can then be redirected <em>from outside the script</em>. Can't do that to a background process.</p>
  
  <p>As noted by the <a href="https://stackoverflow.com/questions/687948#687994">accepted answer</a> to the other question, there exist other scripts that solve that particular problem without attempting job control. Fine. And the lambasted script uses a hard-coded job number &mdash; Obviously bad. But I'm trying to understand whether job control is a fundamentally doomed approach. It still seems like maybe it <em>could</em> work...</p>