Why do some programs return to the shell immediately while others don't until execution is complete?

Question

I have read from the Modern Operating systems book that when a command is run, the shell creates a child process, waits for it until the child has finished execution and then waits for another command from the user. This is indeed the case for many programs like gedit. The terminal doesn't take commands until I have closed gedit. However when I open atom code editor, the shell returns immediately, ready to accept the next command even with the editor running. Closing the terminal does not close atom. Does this mean that the editor opened not as a child process? What is the underlying mechanism that makes this possible?

Running ps au | grep atom gives

<username>      8042  0.0  0.0  15944  2264 pts/1    S+   00:55   0:00 grep --color=auto atom

Answer 1

The question asks about two types of programs:

1. programs which interact with the user in the shell, and
2. programs which do not interact with the user in the shell.

In the first case, programs which interact with the user in the shell are designed to run to completion before returning control to the shell. Nothing special is done.

The second case is more complicated. Typically the program will fork (making a copy of itself in memory), and arrange to remove its association with the shell's controlling terminal, and may execute another program — which runs independently of the original shell. You may see messages from the second program, but it usually does not otherwise interact with you. Depending on how it is used, you may have

• a daemon (server) process, or
• the program may run in a new window. Graphical editors do the latter.

Further reading:

• How do fork and exec work?
• Why do we need to fork to create new processes?
• What's the difference between running a program as a daemon and forking it into background with '&'?
• fork() and exec() confusion