Some GUI apps launch cleanly via the Terminal command line, but some don't, and they cause the Terminal to wait for the app to terminate. Even then, some don't "release" the command line.
The mysterious ampersand &
suffix seems to cause the terminal to put the process into the background (but I'm not sure what happens there).
Is there a way to launch an app via the Terminal so that there is no "hang on" effect, just like launching something via Alt+F2?
I'd like to have the command line available again immediately, without something still in the background and printing in the terminal.
Suppose
gedit
is the program you want to run detached (aka. "disowned", "disentangled", "decoupled"). There are different ways depending on what you want to do exactly:Program already running
Disown:
disown -h
is the way to go if you want to do that with an already running program (i.e. if you forgot tonohup
it). You first have to stop it using Ctrl+Z. Then you can put in in the background usingbg [jobId]
(e.g.bg 1
). You get a list of running jobs with their jobId usingjobs
. After that you can decouple it from terminal usingdisown -h %[jobId]
. Example terminal session:Program not started yet
nohup
nohup
is not always present on all machines. If you know you want to decouple beforehand you would use:Maybe you will want to redirect the shell output as well and your program a pseudo input source, so:
nohup ./myprogram > foo.out 2> bar.err < /dev/null &
. You would want to redirect the output to either not be annoyed by it or to use it later. The null-input can help to prevent hickups in ssh an such.Subshell:
You can achieve a similar effect by
The brackets open a new subshell to run gedit in. The
>/dev/null 2>&1
redirects the shell output to nowhere (suppressing the output). And the&
at the end puts the process in the background.Terminal multiplexing
Also terminal multiplexing using screen or byobu. You basically run the program in a terminal of its own. I can really recommend byobu for other reasons too. Below is a list of boybu-shortcuts that might come in handy for your first steps:
Useful:
Less useful:
The 'at' daemon and others
at
is a nice useful little tool to run a command at a scheduled time. It can be 'misused' to detach a command from the shell:Also you can look into
setsid
andstart-stop-daemon
, but the other methods should suffice.To start an application and detach it from the launched terminal use &!.
It does, and is often what you want. If you forget to use &, you can suspend the program with ctrl-z then place it in the background with the bg command — and continue to use that shell.
The process' stdin, stdout, and stderr are still connected to the terminal; you can redirect those from/to /dev/null or any other file (e.g. save an output log somewhere), as desired:
You can see the process in jobs, bring it back to the foreground (fg command), and send it signals (kill command).
Some graphical programs will detach from the terminal; if that's the case, when you run the command "normally" you'll notice it starts the graphical program and "exits".
Here's a short script, you can place it in ~/bin, which I named runbg:
I look up the program ($prog) before redirecting so errors in locating it can be reported. Run it as "runbg your-command args..."; you can still redirect stdout/err to a file if you need to save output somewhere.
Except for the redirections and error handling, this is equivalent to htorque's answer.
Use
nohup
For example:
In gedit's case, I just keep a copy open all the time. As long as you have an existing copy running, launching
gedit
calls from the terminal and then closing the terminal won't kill gedit.For other things, what other people have said would work too. I'm a fan of
nohup
... But if you need a terminal you can detach but then re-attach to, you want to look atscreen
.irssi
or evenwatch uptime
would be good examples.screen -r
and BOOM, you're back in.screen
is a lot bigger than that and you can combine it withbyobu
for a better terminal experience. Read around.Open the terminal, type screen, type the command you want to run, close the terminal. The program should keep on running in the GNU Screen session.
xdg-open
Have a look at this general-purpose utility: https://linux.die.net/man/1/xdg-open
This will open a relative location in your file manager.
This will open a pdf file in a pdf reader.
You can even provide web URLs
This worked for me:
As a lot of people figured, nohup is the thing to consider. But nohup stills remains open on the terminal and displays the program activity on the terminal which is irritating. You can just close the terminal after that to avoid so. I found out a very simple workaround which I use.
And that's it. It opens gedit and closes the terminal when gedit starts up. As gedit is not associated with the terminal now, it stays active.
This works even inside a script (Like aliases, the '&' trailer is not normally allowed in scripts because they are not interactive):