Terminal Shell Sed30 Nov 2019 • Leave Comments
I was aimed to be an ICT expertise. However, still today, I don't quite get the basics of ICT origin. This post will help clarify the relations between Terminal, Shell and Sed.
This is long story. Let's begin with Terminal. At the very beginning, the only interface with the giant (as big as a house) computer was punched tape along with an human being operator. Afterwards, terminal was created allowing individuals to interact with computer. Terminal is a physical device like the following one:
Usually a computer allows multiple terminals online. Each terminal is capable of input (punched tape was replaced with keyboard then) and output. Specially, I want to emphasize the output part a little bit. Let's go back to the image above, the terminal has a screen with texts displayed, that is the exact output part, namely the console. When we talk console, we refer to the screen part of a physical terminal.
As time flies, standalone terminals were outdated and virtual terminal emerged with smaller computer - Personal Compuer (PC). PC has only one screen and one keyboard embedded but allows switching (
Ctrl-Alt-Fn) between multiple (12 by default) virtual terminals. Virtual terminal is kernel device that provides a means of input and output. It is not a software terminal instead of a physical one. Most often, a virtual terminal has a login manager in front before an account can interact with his default login shell (i.e. POSIX Bash).
Apart from virtual terminal, we have terminal emulator when X window presents. Terminal emulator is similar to a virtual emulator but managed by an X session instead of directly by the kernel.
Now let's move on to Shell. Terminal is where input and output happen (like typing program names), but Shell is a job manager (desktop manager does the same thing). Nowadays, OS (Linux, Unix etc.) schedules multiple processes concurrently, namely mutli-tasking support. Shell is the multi-tasking interface with end users, capable of starting, stopping, suspending, resuming etc. jobs. Upon login, the default Shell is ready for interaction.
With Shell, we can suspend the current job to background with
Ctrl-Z. On the contratry,
fg put the first background job foreground running again. Alternatively,
bg send the job running background instead of suspending it. To start a program running in background, we can append
& to program like
program-name &. Different Shells may have different syntax to manage jobs.
Job is distinct from process, but both of them relate to program. A program is a static executable binary while a process is a running program. Job is only meaningful to Shell. Jobs refer to a pipeline of processes that run interactively. For example,
ls | head launches two processes but the pipeline defines a single job. Therefore, a job of Shell corresponds to a process group of OS. Shell assign each job a job ID apart from process PID assigned by the OS. To list existing jobs, just run
jobs -l like:
user@tux ~ $ sleep 300 &  21810 user@tux ~ $ sleep 301 &  21811 user@tux ~ $ sleep 302 &  21812 user@tux ~/workspace/outsinre.github.com $ jobs -l  21810 Running sleep 300 & - 21811 Running sleep 301 & + 21812 Running sleep 302 &
Numbers in brackets are job IDs while numbers that follow job IDs are PID. More about job control, please refer to Manual 7.1 Job Control Basics .
BTW, a daemon does not belong to job as it _detach_es from Shell and gets out of Shell management. Process suspended or running in background belong to job. Putting a job background allows starting another job as the Shell is _release_d.
Finally, we go to
sed. It is just a sample of the many programs managed by Shell. Nothing more required to clarify.