The numbers between `[]` are the **job ID** numbers and the four digit ones are the **process ID** numbers, or **PID**.
When using the `jobs` command you can sue the job ID to reference a particular job.
For example, run `sleep 30 & sleep 60 & sleep 90 &` and observe the output.
Next run the `jobs` command and not the more verbose output.
All three jobs are **running** and will terminate one by one.
We can bring back a process to the foreground, so we can interact with it from **STDIN**, by running the `fg` command.
If we only have one process running it will bring back this single process but you can choose which one to bring to the foreground by specifying the job ID as such `fg %2` or `fg %3`.
**Can you tell me what the `+` and `-` mean in the jobs list?**
Now, how can we gain control of our terminal again?
Observe the following output:
```
➜ ~ sleep 30 & sleep 60 & sleep 90 &
[1] 13207
[2] 13208
[3] 13209
➜ ~ fg %3
[3] - 13209 running sleep 90
^Z
[3] + 13209 suspended sleep 90
➜ ~ jobs
[1] running sleep 30
[2] - running sleep 60
[3] + suspended sleep 90
➜ ~
```
First we create three jobs that are sent to the background.
Next we bring job ID number 3 back to the foreground.
We send the **suspend** signal to this job by pressing CTRL-Z.
Note the output from `jobs` which now notes two running jobs and one suspended.
This brings us to **signals**.
### Signals
We use signals all the time without realizing it.
The most common signal we have used is the **SIGINT** that we send when pressing **CTRL-C** on a running process.
A second one most of you know by know is CTRL-Z to suspend a running job.
To see all key combination and their signals we can run the `stty -a` command.
Contrary to `jobs`, `kill` uses the **PID** numbers to reference running processes.
The PID of a process is shown when you launch it, or you can inspect the PID of all your jobs by executing `jobs -l`.
To demonstrate how to send signals I advise you to run a few long running sleep commands as follows: `sleep 32234 & sleep 324234 & sleep 72552 & sleep 453445 & sleep 96986996 &`
You can now send signals to these processes with the following syntax `kill -$signal_to_send $PID` where `$signal_to_send` is the signal and `$PID` is the process ID.
The information above is already quite interesting but we can add or remove columns to the output by using the `o` argument as follows.
Note that each process has a **unique** PID but they all share the same PPID (parent process ID).
Or do they?
Why does the first line, in my case `zsh` have a different PPID?
```
➜ ~ ps o pid,ppid,cmd
PID PPID CMD
13510 13509 -zsh
14164 13510 sleep 32234
14165 13510 sleep 324234
14166 13510 sleep 72552
14167 13510 sleep 453445
14168 13510 sleep 96986996
14199 13510 ps o pid,ppid,cmd
➜ ~
```
The list of available columns can be found in the `man ps` pages in the **STANDARD FORMAT SPECIFIERS** section (around line 500).
We can specify a specific process with the `-p $PID` argument.
```
➜ ~ ps o pid,ppid,cmd
PID PPID CMD
14466 14465 -zsh
14640 14466 tmux
14643 14642 -zsh
14681 14643 ps o pid,ppid,cmd
➜ ~ ps o pid,ppid,cmd -p 14643
PID PPID CMD
14643 14642 -zsh
➜ ~
```
Now in this shell I can start a few specific background jobs, simulated with `sleep`.
```
➜ ~ sleep 1111 & sleep 2222 & sleep 3333 &
[1] 14697
[2] 14698
[3] 14699
➜ ~ ps o pid,ppid,cmd
PID PPID CMD
14466 14465 -zsh
14640 14466 tmux
14643 14642 -zsh
14697 14643 sleep 1111
14698 14643 sleep 2222
14699 14643 sleep 3333
14702 14643 ps o pid,ppid,cmd
➜ ~
```
If I now `disown` a specific job ID, or all with the `-a` flag the processes will not be dependent on the parent's existance.
A quick `ps o pid,ppid,cmd` will still show the PPID as parent *but* when you close the parent shell and inspect the specific PID of the disowned process you'll see it's now owned by a *different* parent.
I know it sounds complicated but I urge you to test this all out in a few shells.
The practice will explain it a lot better than some codeblocks.
```
➜ ~ ps o pid,ppid,cmd -p 14698
PID PPID CMD
14698 1 sleep 2222
➜ ~
```
Now why is the process only changing parent once the original parent terminates?
I'm asking you to look for an answer online but the solution can be found the realm of *signals*, especially the *hang up* [signal](https://en.wikipedia.org/wiki/SIGHUP).
Learning how to create them is a bit out of our scope but I highly advise you to read up a bit on [what](https://en.wikipedia.org/wiki/Zombie_process) they are and [how](https://www.howtogeek.com/701971/how-to-kill-zombie-processes-on-linux/) to deal with them.
