[SOLVED] How does '&' make a process run in background ?

Hi,

This is no homework question ! It is just out of curiosity !

emacs abc.c &

Executing the above code runs abc.c in background. I was wondering is & a command/process or what ?

Is & internally related to bg command !

I have read many tutorials regarding pipes '|' and redirection operators '>' but none regarding '&'

Kindly explain !

Maybe it uses a fork() / exec() (Ugh!) without waiting for the child (waitpid()?).

Originally Posted by smeezekitty Maybe it uses a fork() / exec() (Ugh!) without waiting for the child (waitpid()?).

Thanks for bothering !

What made u think that it doesn't wait for the child process ?

Originally Posted by anishakaul What made u think that it doesn't wait for the child process ?

"It" is, of course, the shell.

The reason we know it doesn't wait for the child process to complete is that if it did wait, you wouldn't get your shell prompt back until the waiting was complete.

Originally Posted by anishakaul I was wondering is & a command/process or what ?

The GNU Bash Reference's section on Lists of commands says "the control operator ‘&’" so I guess that makes it a control operator!

Even bash doesn't report that. It reports external commands, built-ins and keywords but not operators

c:~$ type ls
ls is /usr/bin/ls
c:~$ type [
[ is a shell builtin
c:~$ type then
then is a shell keyword
c:~$ type '>'
bash: type: >: not found
c:~$ type '&'
bash: type: &: not found

This thread is a spin off from
http://www.linuxquestions.org/questi...82#post3793682
So if you want to know the context of the question.

The shell works by spawning child processes. Normally, it does so and then waits for the processes to complete.

When you use the "&" operator, the shell launches the child process but does not wait for it to complete. It calls the launched process a "job" and immediately presents you with the command-prompt again.

You can, with the bg and fg commands, switch your attention between any of these processes.

All of these processes are, and remain, "children of the shell."

Also see the nohup command.

Originally Posted by anishakaul Thanks for bothering ! What made u think that it doesn't wait for the child process ?

Well of course it waits for the process to end in the background. If it didnt wait for it at all then the prompt would be blocked until the child is done, which is the same as just running any command normally (the shell is blocked). If it didnt wait to accept the childs return code (in the background), then the child would be an orphan process (or zombie, I forget the terminology).

Originally Posted by sundialsvcs Also see the nohup command.

Thanks for pointing out the nohup command. I unaware of its existence.

Originally Posted by catkin The GNU Bash Reference's section on Lists of commands says "the control operator ‘&’" so I guess that makes it a control operator! Even bash doesn't report that. It reports external commands, built-ins and keywords but not operators

Thanks for the info regarding the operators. I didnt read much details yet, but definitely I will !

Thanks to all others for making the explanation of shell behavior more clear !!

Meanwhile I was wondering is there a command to know the system calls which these commands call internally ??

e.g. printf calls read()
e.g. cd calls chdir()

I tried strace nohup ls & to know the system call nohup must be calling, but couldn't figure out much !

thanks !

It may be easier to read the source code for the utility than to figure it out from strace...

Originally Posted by gnashley It may be easier to read the source code for the utility than to figure it out from strace...

Thanks for the reply,

But i think there should be some other smarter way to figure that out rather than reading the source code !

Originally Posted by sundialsvcs The shell works by spawning child processes. Normally, it does so and then waits for the processes to complete. When you use the "&" operator, the shell launches the child process but does not wait for it to complete. It calls the launched process a "job" and immediately presents you with the command-prompt again.

Partially correct. The shell will still keep track of it unless you disown it; that's how you can put it in the foreground later. The shell is the session leader, which means it controls the terminal and the process groups tied to that terminal. A command line generally constitutes a process group, which has separate processes for each stage of I/O redirection. Normally a new process group is put in the foreground, which means it controls the terminal. When using &, the shell takes terminal control from the process group so that a program blocks (with SIGTTOU) if it requires access to it (other than writing to it like a pipe.) See man tcsetpgrp for more info.
Kevin Barry

This is kind of related. I have wondered -is there a way to retrieve the exit status of a process which was backgrounded?

Originally Posted by gnashley This is kind of related. I have wondered -is there a way to retrieve the exit status of a process which was backgrounded?

Dunno. Maybe jobs -n?