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.

  • At the request of htorque, I deleted his answer that you accepted. Please could you pick another answer (you will have to unselect htorque's first - should be lurking at the bottom of the page in red)
    – Oli
    Jun 1, 2011 at 12:56
  • 1
    The method to deal with a Program-already-running (as outlined by con-f-use) is good for that situation, but as my primary question was about clean-launching with no terminal clutter, I've accepted screen (mentioned by Oli and RobinJ). I am impressed by its capability; after reading about it and trying it out... It only requires the typing of: screen -d -m gedit (or screen gedit then Ctrl+a d to detach)... and I still have full access to gedit's terminal view (for warning messages etc) at any time via screen -r even if I have closed the original terminal window in the meantime...
    – Peter.O
    Jun 4, 2011 at 1:36
  • BTW, some of the things you're attributing to the terminal are actually done by the shell, for example interpreting the & command suffix. This might be helpful for clarification: What is the difference between Terminal, Console, Shell, and Command Line?
    – wjandrea
    Oct 5, 2018 at 16:58
  • sudo -E gedit /tmp/a.txt
    – petep
    Feb 10 at 19:59

11 Answers 11


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 -h is the way to go if you want to do that with an already running program (i.e. if you forgot to nohup it). You first have to stop it using Ctrl+Z. Then you can put in in the background using bg [jobId] (e.g. bg 1). You get a list of running jobs with their jobId using jobs. After that you can decouple it from terminal using disown -h %[jobId]. Example terminal session:

$ gedit 
[1]+  Stopped                 gedit
$ jobs
[1]+  Stopped                 gedit
$ bg 1
[1]+ gedit &
$ disown -h %1
$ exit

Program not started yet


nohup is not always present on all machines. If you know you want to decouple beforehand you would use:

nohup gedit &

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.


You can achieve a similar effect by

$ (geany >/dev/null 2>&1 &)

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:


  • F2 Create a new window
  • F3 Move to the next window
  • F4 Move to the previous window
  • F6 Detach from the session and logout
  • Shift-F6 Detach from the session, but do not logout
  • F7 Enter scrollback/search mode
  • Ctrl-F5 Reconnect any SSH/GPG sockets or agents

Less useful:

  • Shift-F2 Split the screen horizontally
  • Ctrl-F2 Split the screen vertically
  • Shift-F3 Move focus to the next split
  • Shift-F4 Move focus to the previous split
  • Shift-F5 Collapse all splits
  • F5 Refresh all status notifications
  • F8 Rename the current window
  • F9 Launch the Byobu Configuration Menu
  • F12 GNU Screen's Escape Key
  • Alt-Pageup Scroll back through this window's history
  • Alt-Pagedown Scroll forward through this window's history
  • Ctrl-a-! Toggle all of Byobu's keybindings on or off

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:

echo './myprogram myoption1 myoption2' | at now

Also you can look into setsid and start-stop-daemon, but the other methods should suffice.

  • Tip: if there's just one job, the job ID is optional, e.g. instead of bg %1 you can just type bg. Mar 15, 2016 at 12:51

To start an application and detach it from the launched terminal use zsh's &!.

firefox &!
  • 8
    Good to know, but that seems to be zsh-only. In bash you'd have to manually run disown <pid-of-command> after starting the command in the background.
    – htorque
    Oct 31, 2010 at 12:29
  • Interesting... I'm going to look into zsh, but as a Linux newbie, I'll stick with bash for now... Thanks
    – Peter.O
    Nov 1, 2010 at 2:55
  • what does the exclamation mark do ? Jan 13, 2013 at 17:30
  • 1
    The ! will break the application process from the terminal process so that you can close the terminal without the application that was launched from closing. It seems to be a zsh thing, but handy.
    – Rick
    Jan 14, 2013 at 14:21
  • 1
    But this worked in bash too @htorque .... So I guess it's not a problem.
    – Jasser
    Mar 22, 2016 at 9:16

The mysterious ampersand "&" suffix, seems to cause the terminal to put the process into the background... (but I'm not sure what happens there).

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:

some-program </dev/null &>/dev/null &
# &>file is bash for 1>file 2>&1

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:

[ $# -eq 0 ] && {  # $# is number of args
  echo "$(basename $0): missing command" >&2
  exit 1
prog="$(which "$1")"  # see below
[ -z "$prog" ] && {
  echo "$(basename $0): unknown command: $1" >&2
  exit 1
shift  # remove $1, now $prog, from args
tty -s && exec </dev/null      # if stdin is a terminal, redirect from null
tty -s <&1 && exec >/dev/null  # if stdout is a terminal, redirect to null
tty -s <&2 && exec 2>&1        # stderr to stdout (which might not be null)
"$prog" "$@" &  # $@ is all args

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.

  • Okay, thanks... It seems that ctrl-z (suspend) gives me access to the command line again, but blanks out the GUI until I issue bg which seems to un-suspend it. (makes sense)... Is there another command by which I can detach the GUI... Aha! I see now what you mean by sighals (kill command)... (interesting things these signals).. I used a code snippet to make dd progressively output it stats.. and it used kill + a SIGNAL... Is there a specific SIGNAL to detach a "job"?
    – Peter.O
    Oct 31, 2010 at 12:41
  • I just noticed your comment to Rick's answer... I tried disown jobs -p gedit`` and it seemd to remove the job.... (but I got system messages in the Terminal when I manually closed gedit... but I think I've got a screwed-up Terminal at the moment... too much experimenting :(
    – Peter.O
    Oct 31, 2010 at 12:51
  • @fred: Jobs are managed by the shell, so no signal can control that. You may find it works best to start several shells — several GUI terminals allow tabs and you can use screen or tmux.
    – Roger Pate
    Oct 31, 2010 at 12:52
  • 2
    @fred: better don't run jobs -p command if you have multiple instances of one command running in the background at a time. you can use jobs to find the right job id and then do jobs -p <job-id> to get the job's PID. Personally I find the version with the subshell a lot easier. ;-)
    – htorque
    Oct 31, 2010 at 13:22
  • 2
    @htorque, fred: You can run disown without parameters to have bash disown the last job: gedit & disown
    – Roger Pate
    Oct 31, 2010 at 13:32

Use nohup

nohup is a program that runs a given command with hangup signals ignored, so that the command can continue running in the background after its parent process terminates. See the manpage

For example:

nohup gedit something
  • 2
    What is nohup? Please elaborate.
    – Oxwivi
    May 31, 2011 at 12:15
  • 3
    nohup is a program that runs a given command with hangup signals ignored, so that the command can continue running in the background after its parent process terminates. See the manpage May 31, 2011 at 12:23
  • Actually I think my answer is incorrect here. On further thought, nohup should be used in this scenario.
    – boehj
    May 31, 2011 at 12:26
  • 2
    When an interactive shell receive a SIGHUP signal, can send (or not, depending on settings) a SIGHUP signal to all of its childs. This can happen (or not, again) when a terminal is closed. A child not ready to handle such a signal will execute the default action, i.e. exit. The nohup application (and the disown bash builtin) do not allow the signal to reach the application.
    – enzotib
    May 31, 2011 at 12:33
  • 2
    One thing to be careful of is that nohup creates a file in the current directory called nohup.out. See the man page for more details. I prefer disown for this reason, and for the fact that disown works after you launch gedit.
    – Flimm
    May 31, 2011 at 14:17

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 at screen.

  1. Run it in a terminal and then run something that keeps pushing output. I use the Django development server but irssi or even watch uptime would be good examples.
  2. Kill the terminal and start a new one.
  3. Run screen -r and BOOM, you're back in.

screen is a lot bigger than that and you can combine it with byobu for a better terminal experience. Read around.

  • This is the first real insight I've had as to what screen does/can do... thanks for the terminal tip...
    – Peter.O
    Jun 4, 2011 at 1:30
  • 1
    screen is no longer available, but tmux can replace screen. (tmux to start a new tmux session, ctrl+b, then press d to deatach, and tmux attach to reattach) Apr 2, 2016 at 13:25

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.

  • What exactly is GNU Screen?
    – Oxwivi
    May 31, 2011 at 15:11
  • If I get the idea correctly, it's a kind of window manager for the command line. It allows you to run more than one program at once in a command line interface session.
    – RobinJ
    May 31, 2011 at 15:14
  • Byobu?
    – Oxwivi
    May 31, 2011 at 15:38
  • Something like that, only Byobu is easier to use. If I am npot mistaken, Byobu is just an easier interface for GNU Screen.
    – RobinJ
    May 31, 2011 at 15:39
  • It ALMOST works perfectly in BASH. The only minor complaint being that you get notifications of background status when the process starts and stops. Linux is so darned strange coming from windows world. You would think this would totally be A Thing.Just start the darned thing, and stop spewing status messages from the dark ages of computing that truly nobody cares about all over my terminal. lol. Feb 11, 2021 at 22:05


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.

 $ xdg-open .

This will open a pdf file in a pdf reader.

 $ xdg-open foo.pdf

You can even provide web URLs

$ xdg-open www.google.com

This worked for me:

$ (nohup gedit 2>/dev/null &)

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.

nohup gedit & exit

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):

bash -i >/dev/null 2>&1 <<<'nohup gedit &'

This worked for me:

$ (some-program &) &>/dev/null

# Examples:
$ (gedit &) &>/dev/null
$ (google-chrome &) &>/dev/null

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .