job-control

How can I run a shell script and immediately background it, however keep the ability to inspect its output any time by tailing /tmp/output.txt It would be nice if I can foreground the process too later. PS It would be really cool if you can also show me how to "send" the backgrounded process in to a gnu screen that may or may not have been initialized. To 'background' a process when you start it Simply add an ampersand ( & ) after the command. If the program writes to standard out, it will still write to your console/terminal. To foreground the process, simply use the fg command. (You can see

To maximize CPU usage (I run things on a Debian Lenny in EC2) I have a simple script to launch jobs in parallel: #!/bin/bash for i in apache-200901*.log; do echo "Processing $i ..."; do_something_important; done & for i in apache-200902*.log; do echo "Processing $i ..."; do_something_important; done & for i in apache-200903*.log; do echo "Processing $i ..."; do_something_important; done & for i in apache-200904*.log; do echo "Processing $i ..."; do_something_important; done & ... I'm quite satisfied with this working solution, however I couldn't figure out how to write further code which only

How do I kill the last spawned background task in linux? Example: doSomething doAnotherThing doB & doC doD #kill doB ???? There's a special variable for this in bash: kill $! $! expands to the PID of the last process executed in the background. You can kill by job number. When you put a task in the background you'll see something like: $ ./script & [1] 35341 That [1] is the job number and can be referenced like: $ kill %1 $ kill %% # Most recent background job To see a list of job numbers use the jobs command. More from man bash : There are a number of ways to refer to a job in the shell. The

In this answer to another question , I was told that in scripts you don't have job control (and trying to turn it on is stupid) 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. [ Update: 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.] So why doesn't script-based job-control work, and what makes it a bad practice (aka 'stupid')? Edit: The script in question starts

In a comment on this answer of another question , the commenter says: don’t use kill -9 unless absolutely necessary! SIGKILL can’t be trapped so the killed program can’t run any shutdown routines to e.g. erase temporary files. First try HUP (1), then INT (2), then QUIT (3) I agree in principle about SIGKILL , but the rest is news to me. Given that the default signal sent by kill is SIGTERM , I would expect it is the most-commonly expected signal for graceful shutdown of an arbitrary process. Also, I have seen SIGHUP used for non-terminating reasons, such as telling a daemon "re-read your