You are not logged in.

#1 2013-02-03 13:05:11

Gullible Jones
Member
Registered: 2004-12-29
Posts: 4,863

A better way of forking programs from terminals

Run

gvim blah_file

from a terminal, and gvim hangs around dumping output to STDOUT. Run

gvim blah_file &

and it backgrounds, but requires the terminal to remain open or it will crash. Run

(gvim blah_file &)

and you get more or less what I want, which is for gvim to launch in the background, leave the terminal free, and not require it to remain open.

The problem is, I don't like typing the parentheses. smile Is there another way to achieve the same result?

Offline

#2 2013-02-03 13:10:29

olive
Member
From: Belgium
Registered: 2008-06-22
Posts: 1,490

Re: A better way of forking programs from terminals

You can disown them (man bash). I have put

PROMPT_COMMAND=${PROMPT_COMMAND:+$PROMPT_COMMAND; }'disown -a -h'

in my ~/.bashrc with the effect that if you launch a program in the background (with &). It will not be stopped when you close the terminal.

Last edited by olive (2013-02-03 13:11:53)

Offline

#3 2013-02-03 13:15:28

Gullible Jones
Member
Registered: 2004-12-29
Posts: 4,863

Re: A better way of forking programs from terminals

Ah, more PROMPT_COMMAND magic. Thanks!

Offline

#4 2013-02-03 13:22:14

brebs
Member
Registered: 2007-04-03
Posts: 3,742

Re: A better way of forking programs from terminals

Gullible Jones wrote:

requires the terminal to remain open or it will crash

gvim works fine for me - doesn't have that problem. I would suggest looking at your version of ncurses (lotsa patches, I'm upto patch 20130119) and gvim.

Offline

#5 2013-02-03 13:29:57

olive
Member
From: Belgium
Registered: 2008-06-22
Posts: 1,490

Re: A better way of forking programs from terminals

brebs wrote:

gvim works fine for me - doesn't have that problem. I would suggest looking at your version of ncurses (lotsa patches, I'm upto patch 20130119) and gvim.

The problem is for graphical program (thus nothing  to do with ncurses). Bash send a SIGHUP signal to all process it has launched when we close its terminal (try firefox &  or emacs &). My solution automatically disown them and prevent this.

Last edited by olive (2013-02-03 13:36:31)

Offline

#6 2013-02-03 13:45:17

brebs
Member
Registered: 2007-04-03
Posts: 3,742

Re: A better way of forking programs from terminals

I don't have this problem at all. Maybe because I run xorg using startx-ish?

alias x='setsid /usr/bin/startx -- -nolisten tcp &> ~/.xorg.log & logout'

Edit: I didn't have such a problem when I was running just plain "startx" either.

Last edited by brebs (2013-02-03 13:47:48)

Offline

#7 2013-02-03 13:58:09

Gullible Jones
Member
Registered: 2004-12-29
Posts: 4,863

Re: A better way of forking programs from terminals

To be technical it's not a crash; the application just gets the hang-up signal and does what it's supposed to.

Offline

#8 2013-02-03 13:59:56

olive
Member
From: Belgium
Registered: 2008-06-22
Posts: 1,490

Re: A better way of forking programs from terminals

At least two people do not seem to understand the question. This has nothing to do with the way we launch X. To "reproduce it", launch a terminal in a graphical environment and be sure your shell is bash. In this terminal type (assuming firefox is not running):

firefox &
or
xeyes &
or
emacs &

Then close the terminal and see that firefox is closed. This is a feature of bash that send the SIGHUP signal to all the processes it has launched. Some people (including me) don't like it. Some GUI programs ignore the HUP signal and stay alive (it seems to be the case for gvim).

Last edited by olive (2013-02-03 14:14:04)

Offline

#9 2013-02-03 14:03:23

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,422
Website

Re: A better way of forking programs from terminals

man nohup


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#10 2013-02-03 14:10:45

olive
Member
From: Belgium
Registered: 2008-06-22
Posts: 1,490

Re: A better way of forking programs from terminals

Trilby wrote:

man nohup

And experience it with emacs:

nohup emacs &

and close the terminal. You will see that "nohup" just doesn't work. The reason is that even when launched with nohup, emacs remain a bash "job" and receive the SIGHUP signal directly from bash. Moreover, my solution work without having to take extra care about program we launch in the background.

Last edited by olive (2013-02-03 14:13:00)

Offline

#11 2013-02-03 14:38:54

WesleyDimble
Member
Registered: 2012-09-03
Posts: 18

Re: A better way of forking programs from terminals

If you aren't set on bash, zsh has some nice syntax for disowning jobs. Just stick a &| at the end of your command, instead of the usual &.

Offline

#12 2013-02-03 15:07:37

Gullible Jones
Member
Registered: 2004-12-29
Posts: 4,863

Re: A better way of forking programs from terminals

And thank you as well, WesleyDimble. I'll keep that in mind, though for now I'm sticking with bash.

Re gvim, I was using it as an arbitrary example. I hadn't realized that it ignored HUP.

Offline

#13 2013-02-03 15:11:03

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,422
Website

Re: A better way of forking programs from terminals

olive wrote:
nohup emacs &

and close the terminal. You will see that "nohup" just doesn't work.

It works just fine here.

Something is wrong with your setup if it doesn't.  nohup means NO-HUP, as in the SIGHUP is not sent.

But one could also try setsid for even more "detachment".


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#14 2013-02-03 16:34:02

karol
Archivist
Registered: 2009-05-06
Posts: 25,440

Re: A better way of forking programs from terminals

+1 for nohup. You can use a bash function for even less typing or a launcher like dmenu, but I don't know if it supports arguments like 'blah_file' from 'gvim blah_file'.

Offline

#15 2013-02-03 16:35:39

thisoldman
Member
From: Pittsburgh
Registered: 2009-04-25
Posts: 1,172

Re: A better way of forking programs from terminals

I can only partially reproduce the problem and only with emacs.  Gvim doesn't have this problem.  I've tried this with both xterm and urxvt and bash is the only shell I use.

The only way emacs disappears is if I close the terminal window with 'Alt-F4'.  I'm using Openbox as my WM and have Alt-F4 set up as:

    <!-- Close window. -->
    <keybind key="A-F4">
      <action name="Close"/>
    </keybind>

When I close the terminal by typing exit or using Ctrl-d, or by using the close window button (the button with the 'X'), emacs stays and is fully functional.  But Alt-F4 makes emacs disappear.

Edit: I take back what I said about the close button.  Its effect isn't consistent.  Sometimes emacs stays and is functional, sometimes it stays and is partially locked up – menus won't close or won't function.  Other times, emacs disappears with the terminal.  I finally got a warning message with the start of emacs:

 (emacs:1817): GLib-WARNING **: In call to g_spawn_sync(), exit status of a          
child process was requested but SIGCHLD action was set to SIG_IGN and ECHILD    
was received by waitpid(), so exit status can't be returned. This is a bug in   
the program calling g_spawn_sync(); either don't request the exit status, or    
don't set the SIGCHLD action.

Last edited by thisoldman (2013-02-03 17:00:52)

Offline

#16 2013-02-18 16:55:31

Gullible Jones
Member
Registered: 2004-12-29
Posts: 4,863

Re: A better way of forking programs from terminals

Hmm. I've noticed that 'disown -a -h' does not suppress stderr output, which some programs generate a lot of. Is there any way to automatically suppress it when backgrounding a process, so it doesn't clog up my terminal?

Offline

#17 2013-02-18 17:17:05

olive
Member
From: Belgium
Registered: 2008-06-22
Posts: 1,490

Re: A better way of forking programs from terminals

Gullible Jones wrote:

Hmm. I've noticed that 'disown -a -h' does not suppress stderr output, which some programs generate a lot of. Is there any way to automatically suppress it when backgrounding a process, so it doesn't clog up my terminal?

I do not think so, at least not with the usual & syntax. You can do it for a given program at a time (see below) but I do not see a general solution. If you are concerned by the program foo, you can put the following in your ~/.bashrc

foo() {
foo 2> /dev/null
}

or more generally, you can define:

launch_in_background () {
"$@"  2> /dev/null &
}

The latter suggestion have problems with command completion (it is possible to correct it via programmable completion but my knowledge ends here).

Last edited by olive (2013-02-18 17:18:14)

Offline

Board footer

Powered by FluxBB