What can be used to spawn a completely seperate process in Bourne Shell (Or csh)

开发者_Go百科

I'm testing out a way to run a process separate from the original process in sh. I've already asked and heard that & is used for spawning a child process. By calling a program, in this case glxgears, because it has a lot of STDOUT (so I can test where output goes), using backticks.

glxgears&

does not keep output out of the current shell where

`glxgears`&

causes

comp:~ user$ `glxgears`&
[1] 14511
comp:~ user$ X connection to /tmp/launch-dZalNv/org.x:0 broken (explicit kill or server shutdown).

[1]+  Exit 1                  `glxgears`
comp:~ user$

I accept that [1] 14511 is just notification of proper process launch, but how is the X Server still able to dump output in my shell? And why if I have launched a separate process is

[1]+  Exit 1                  `glxgears`

Showing up? The shell never warns me of other closing processes!

I think I've deduced that it may have to do with the process group which remains the PID of my shell even after my shell is closed. All other processes have their own process group. Even using

`glxgears&`&

retains the original shell's PID as the process group!

I want to be able to run a program (in this case glxgears) without any association to the launching shell, no output of any kind.

If you could also explain why the X server can send my starting process the output that be very much appreciated.

---

Try this:

nohup glxgears >/dev/null 2>&1 &

• 2>&1 makes the program's stderr to be stdout.
• >/dev/null makes stdout to be /dev/null, so that you will see nothing on your terminal, and the program will not receive a boken pipe signal if you close your terminal
• With nohup, the program will not terminate if its parent is terminated

---

You seem to be confusing process association with I/O streams. The only thing special about background processes is that they return interactive control to the calling shell, nothing more. They still use the same stdout and stderr streams of the same terminal. Where else would they write output to? The only semi-reasonable things to do would be (a) to discard output completely (b) to point them to some new file. Both were considered too unlikely to be useful to be the default behavior, so the default is still to use the terminal of the calling process for output. You can override this choice with the > operator, as arnaud has shown.