Run a command without making me wait
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!
See also How do you send command line apps directly to the background? if you already started the command and want to send it to the background.
Before running the command, you can append
&to the command line to run in the background:
After starting a command, you can press CtrlZ to suspend it, and then
bgto 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
@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.
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.outin 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
disownbut 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.
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).
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 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.
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.logwhich you can specify. If you don't care to store the output at all - you can use
/dev/nullinstead of an actual file.
&will execute command in the background so that you can continue inputting commands while it is running.
2>&1redirects 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:
 1234This 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
thank you, `2>&1` is very important coz the command can fail and try it output the error in some cases!
$ 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.
(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 -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.
You can run a program in the background using
&. For example, if you wanted to run
yum install XyZfor example, you could run:
yum install XyZ &
stdoutor 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
yumin a file
yum install XyZ > yum.log &
Or, if you wanted to add the output to an existing file
yum install XyZ >> log &
Errors are printed to
stdout, and can be redirected to a file in the same way, but using
yum install XyZ 2> errors yum install XyZ 2>> errors
If you wanted to redirect both
stdout, you can use
yum install XyZ &> output yum install XyZ &>> output
You can run a command in the background simply by putting
&sign after it.
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
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.