141

On the CLI, sometimes a command I type takes a while to complete, and sometimes I know when that's about to happen. I'm a bit confused on "backgrounding" and such in Linux.

What is the most common (or user-friendly way) of telling the CLI that I don't want to wait, please give me back my prompt immediately. And if it could give me a progress bar or just busy-spinner, that would be great!

150

Before running the command, you can append & to the command line to run in the background:

long-running-command &

After starting a command, you can press CtrlZ to suspend it, and then bg to put it in the background:

long-running-command
[Ctrl+Z]
bg
  • I used "find ~/ a.java &" command but i didn't went in background? Also, I tried cmd+z (for mac) ....it's not working – Abhimanyu Aryan Aug 5 '15 at 10:08
  • 1
    @AbhimanyuAryan, maybe you want to debug your find ... command first, then run it in the background. In this case you were missing the -name option. – Alexis Wilke Aug 18 '16 at 5:19
112

This is the favorite of all since apart of sending the process into the background you don't have to worry about the text output dirtying your terminal:

nohup command &

This not only runs the process in background, also generates a log (called nohup.out in the current directory, if that's not possible, your home directory) and if you close/logout the current shell the process is not killed by preventing the child proccess from recieving the parent signals when killed (ie. logging out, by SIGHUP to the parent, or closing the current shell).

There's other called disown but that's rather a extension of other answers rather that a method in itself:

command & # our program is in background
disown # now it detached itself of the shell, you can do whatever you want

These commands do not allows you to recover easily the process outputs unless you use a hackish way to get it done.

  • 4
    Sysadmin since '95. Never heard of disown until today, thanks! It doesn't work with every shell though (checked bash, zsh, tcsh. tcsh did not work). – yoonix Dec 5 '13 at 2:36
  • Using nohup in a job control shell is silly. Modern shells don't send HUP to background processes. Redirecting to a unique filename is a small price to pay. – chicks Nov 4 '15 at 16:47
  • @chicks the use case here is to prevent the stderr and stdout to pollute the terminal with the plus that it creates a log file automatically. – Braiam Nov 4 '15 at 16:50
  • 1
    command > file.log 2>&1 & disown is a bit longer than nohup command & but I guess that's what @chicks was suggesting. – joeytwiddle Sep 1 '16 at 7:33
28

This is probably what you want

my_command > output.log 2>&1 &

this will start your command, redirecting both stdout and stderr to some output.log which you can specify. If you don't care to store the output at all - you can use /dev/null instead of an actual file.

& will execute command in the background so that you can continue inputting commands while it is running. 2>&1 redirects stderr to stdout so that all output is caught.

also, when you run a command like this, you should get a confirmation from the kernel similar to this: [2] 1234 This means that your process is running in the background and its id is 1234, so you can kill it later if you wish with kill -9 1234

  • 2
    thank you, 2>&1 is very important coz the command can fail and try it output the error in some cases! – ericn Jun 16 '17 at 3:09
  • 1
    This one worked when the above answers didn't thanks. – Domagoj Oct 1 '18 at 7:30
9

Look into screen or tmux. An example with tmux:

$ tmux new -d 'longrunningcommand'

While the other answers using '&' to background will work, you have to redirect stdout (and stderr!). Without doing that, the output will go straight to your shell, mixing with whatever other output you may have.

Backgrounding will also fail if you're running a long command and log out or get disconnected. The system will kill your job.

If you aren't familiar with either screen or tmux, they basically allow you to completely detach from your shell. Instead of backgrounding your program, you background the whole shell. You can then switch back to it later, even from another computer. They both have a ton more features that you may or may not find useful beyond this use case.

Screen is the old tried and true program; tmux is much younger but has learned from screen's past.

  • This answer misses an actual answer and sounds like a RTFM. – Lloeki Jun 20 '17 at 12:54
5

(For completeness-- answered already:) You put a command in the background by adding & after the command:

long_command with arguments > redirection &

I'm adding this answer to address the other part of your question:

There's no real equivalent of the spinner for showing in-progress background commands, but you can see the status of background commands by typing jobs or jobs -l. It'll show you your backgrounded commands, and whether they're running, stopped via signal (e.g., with ^Z), or occasionally stopped because they're waiting for interactive input from you.

  • long_command with arguments &> redirection & to redirect the stderr too – Ice-Blaze Jan 11 '17 at 7:24
3

You can run a program in the background using &. For example, if you wanted to run yum install XyZ for example, you could run:

yum install XyZ &

The stdout or output from the program can be redirected using > to overwrite a file, or >> to append to a file. For example, if you wanted to log yum in a file yum.log:

yum install XyZ > yum.log &

Or, if you wanted to add the output to an existing file log:

yum install XyZ >> log &

Errors are printed to stderr and not stdout, and can be redirected to a file in the same way, but using 2>:

yum install XyZ 2> errors
yum install XyZ 2>> errors

If you wanted to redirect both stderr and stdout, you can use &>:

yum install XyZ &> output
yum install XyZ &>> output
2

You can run a command in the background simply by putting & sign after it.

For example:

areallylong_command &

will run it in the background.

You can further redirect the stdout/stderr to appropriate files so that they don't appear on your terminal while you are doing something.

See this for more info: http://tldp.org/HOWTO/Bash-Prog-Intro-HOWTO-3.html

0

Try using the 'screen' command before you start your long running task then when you detach you can reattach back to with 'screen -r -d' whenever you need to again. I find that when using a terminal over ssh or other network connections they can sometimes get broken by a bad connection to the server. running it inside a 'screen' fixes this issue.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.