4

I would search for this, but I have no idea how to phrase it for the search engine..

Basically, when I start a gui program from a terminal window, that terminal cannot be further used until I quit the program. I've just started using dwm, and I don't want to have useless terminals littered around after starting up a few graphical programs.. Is there any way around this?

6 Answers 6

10

Everyone saying to use "&" is right. If you happen to forget, type ^Z (ctrl+Z) to suspend the program, then "bg" to tell the shell to run it in the background. That leaves the shell fully interactive just as if you had started the program with the "&".

5

I realize this is an old thread, but I remember finding a more elaborate solution than those listed here.

$ (gui_app &> /dev/null &)

"&> /dev/null" redirects both stdout and stderr to the null device. The last ampersand makes the process run in the background. The parentheses around the command will cause your "gui_app" to run in a subshell.

Doing this will detach the "gui_app" process from the console you execute this command from. So even if you close the window parent terminal emulator is running in, "gui_app" won't close. I ran this then looked at the process tree with "pstree" command and found an application started this way will become child process to "init".

For example,

$ gui_app &> /dev/null &

will run the application in the background, but it will become a child process of the console process and will terminate when you close the terminal. (Though exiting the terminal through bash by using the exit command or Ctrl-D will let bash clean up by handing off the background process to init.)

Alternatively, you can use "nohup", but that redirects output & error to a file by default. "disown" command (if available in shell) can detach process from terminal after you've started a background process:

$ gui_app &
$ disown

(BTW all of this applies to bash. I'm sure other shells have other methods/syntax for doing this.)

Similar superuser Q&A - maybe where I remember some of the answers from: ... start GUI linux programs from the command line, but separate from the command line?

Some reference: Disowning Processes (UNIX Power Tools)

If it's a simple call to a GUI application - without complicated options and such - it seems using a launcher like "gmrun" or dmenu (warning: loud audio) is also a good option. Bind it to a key combination. I don't use a launcher yet but have tried those two.

NOTE: CarlF in the comments reports GUI apps started via "gui_app &" method does not close when he exits from the parent terminal. I think that we were closing the terminal in different ways. I was closing the window the terminal emulator was running in. I think he may have been exiting the terminal emulator through the shell (exit command or Ctrl-D). I tested this and saw that exiting through bash does not stop GUI started as terminal's background process as CarlF says. It seems bash hands off background processes to init when it is given the chance to clean up. In fact, this must be the mechanism by which the background process started in a subshell gets handed off to init.

5
  • 1
    In general, if you run a GUI app from a shell in the background, closing the shell does not close the app.
    – CarlF
    Apr 4, 2011 at 14:02
  • @CarlF I don't know how your system is set up, but I'm using bash on gnome-terminal. If I run "emacs &" then close the console, emacs exits.
    – EMPraptor
    Apr 4, 2011 at 18:06
  • 1
    @EMPraptor, I just tested and whether I use xterm or GNOME Terminal (and bash as the shell), I can start programs (e.g. gedit, oowriter, firefox) and close the parent terminal without closing the GUI app. Ubuntu Lucid Lynx, both with default GNOME session and icwem. I don't have emacs installed to test.
    – CarlF
    Apr 5, 2011 at 1:52
  • @CarF Close the terminal not through shell (e.g. "exit" or Ctrl-D) but close the window hosting the terminal with the method of window manager of your choice. For example, the "X" close window button on Gnome/KDE or "alt-shift-C" on dwm. Your shell will not detach the child process and the GUI application you started via "gedit &" method will close.
    – EMPraptor
    Apr 5, 2011 at 4:11
  • @CarlF Thanks for pointing out that background processes don't stop when you exit through bash. I never tried exiting the terminal through bash in testing for this question. I edited my answer to reflect this.
    – EMPraptor
    Apr 5, 2011 at 4:39
3

You need to start the application in the background like this:

# xeyes &

The & indicates that the application should launch in the background.

1

Put an ampersand (&) after the command and it will put it in the background allowing you to utilize the terminal, example:

nautilus /home/john&
0

try

$>FooBargGui &

this will tell the shell to start the process/gui FooBarGui as background process and return to the prompt immediately.

0

You likely want to redirect any output from the command to /dev/null, as well as background it. IIRC:

command > /dev/null 2>&1 &

When I was using a Sharp Zaurus PDA running Linux (and, IIRC, I was using the OpenBox window manager), I had a bash file I called q, for "Queue it up, quickly and quietly". You could then run, say:

q mycommand param1 param2

I believe this is how the script worked:

#!/bin/bash

$@ > /dev/null 2>&1 &
1
  • Yes, right answer. If you background certain programs, you can still use the terminal, but then closing the terminal window will cause the terminal to hang or the GUI program to quit.
    – Lee B
    Oct 27, 2009 at 20:40

You must log in to answer this question.

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