How can I Shell have more than one job in Linux

Question

I'm a beginner in Linux, just have some questions about job and process group.

My textbook says 'Unix shells use the abstraction of a job to represent the processes that are created as a result of evaluating a single command line. At any point in time, there is at most one foreground job and zero or more background jobs.

Lets say we have this simple shell code(I leave out some unimportant code, ie setup argv etc):

When we type the first commnad, for example: ./exampleProgram &

Q1- Is a job created? if yes, what process does the job contain?

the main() of shellex.c is invoked, so when execute the line 15: fork() create a new child process, lets say the parent process is p1, and the newly created child process is c1 and if it is background job, then we can type another command in the prompt, ./anotherProgram & and type enter

Q2- I'm pretty sure it just p1 and c1 at the moment and p1 is executing the second command, when it execute the line 15: fork() again, we have p1, c1 and new created c2, is my understanding correct?

Q3- How many job is there? is it just one job that contains p1, c1, and c2?

Q4- if it is only one job, so when we keeps typing new commands we will only have one job contains one parent process p1 and many child processes c1, c2, c3, c4... so why my textbook says that Shell can have more than one job? and why there is at most one foreground job and zero or more background jobs.

Answer 1

There is quite a bit to say on this topic, some of which can fit in an answer, and most of which will require further reading.

For Q1 , I would say conceptually yes, but jobs are not automatic, and job tracking and control are not magical. I don't see any logic in the code snippits you've show that eg establishes and maintains a jobs table. I understand it's just a sample, so maybe the job control logic is elsewhere. Job control is a feature of common, existing Unix shells, but if a person writes a new Unix shell from scratch, job control features would need to be added, as code / logic.

For Q2 , the way you've put it is not how I would put it. After the first call to fork() , yes there is a p1 and a c1, but recognize that at first, p1 and c1 are different instances of the same program ( shellex ); only after the call to execve() is exampleProgram running. fork() creates a child instance of shellex , and execve() causes the child instance of shellex to be replaced (in RAM) by exampleProgram (assuming that's the value of argv[0] ).

There is no real sense in which the parent is "executing" the child, nor the process that replaces the child upon execve() , except just to get them going. The parent starts the child and might wait for the child execution to complete, but really a parent and its whole hierarchy of child processes are all executing each on its own, being executed by the kernel.

But yes, if told that the program to run should be run in the background, then shellex will accept further input, and upon the next call to fork() , there will be the parent shellex with two child processes. And again, at first the child c2 will be an instance of shellex , quickly replaced via execve() by whatever program has been named.

(Regarding running in the background, whether or not & has that effect depends upon the logic inside the function named parseline() in the sample code. Shells I'm familiar with use & to say "run this in the background", but there is nothing special nor magical about that. A newly-written Unix shell can do it some other way, with a trailing + , or a leading BG: , or whatever the shell author decides to do.

For Q3 and Q4 , the first thing to recognize is that the parent you are calling p1 is the shell program that you've shown. So, no, p1 would not be part of the job.

In Unix, a job is a collection of processes that execute as part of a single pipeline. Thus a job can consist of one process or many. Such processes remain attached to the terminal from which they are run, but might be in the foreground (running and interactive), suspended, or in the background (running, not interactive).

one process, foreground    : ls -lR
one process, background    : ls -lR &
one process, background    : ls -lR, then CTRL-Z, then bg
many processes, foreground : ls -lR | grep perl | sed 's/^.*\.//'
many processes, background : ls -lR | grep perl | sed 's/^.*\.//' &

To see jobs vs. processes empirically, run a pipeline in the background (the 5th of the 5 examples above), and while it is running use ps to show you the process IDs and the process group IDs. eg, on my Mac's version of bash, that's:

$ ls -lR | grep perl | sed 's/^.*\.//' &
[1] 2454                     <-- job 1, PID of the sed is 2454

$ ps -o command,pid,pgid
COMMAND         PID  PGID
vim            2450  2450    <-- running in a different tab
ls -lR         2452  2452    }
grep perl      2453  2452    }-- 3 PIDs, 1 PGID
sed s/^.*\.//  2454  2452    }

In contrast to this attachment to the shell and the terminal, a daemon detaches from both. When starting a daemon, the parent uses fork() to start a child process, but then exits, leaving only the child running, and now with a parent of PID 1. The child closes down stdin , stdout , and stderr , since those are meaningless, since a daemon runs "headless".

But in a shell, the parent -- which, again, is the shell -- stays running either wait() ing (foreground child program), or not wait() ing (background child program), and the child typically retains use of stdin , stdout , and stderr (although, these might be redirected to files, etc.)

And, a shell can invoke sub-shells, and of course any program that is run can fork() its own child processes, and so on. So the hierarchy of processes can become quite deep. Without specific action otherwise, a child process will be in the same process group as it's parent.

Here are some articles for further reading:

What is difference between a job and a process in Unix?

https://unix.stackexchange.com/questions/4214/what-is-the-difference-between-a-job-and-a-process

https://unix.stackexchange.com/questions/363126/why-is-process-not-part-of-expected-process-group

Bash Reference Manual; Job Control

Bash Reference Manual; Job Control Basics

Answer 2

A job is not a Linux thing, it's not a background process, it's something your particular shell defines to be a "job".

Typically a shell introduces the notion of "job" to do job control . This normally includes a way to identify a job and perform actions on it, like

• bring into foreground
• put into background
• stop
• resume
• kill

If a shell has no means to do any of this, it makes little sense to talk about jobs.