Introduction to Systems Programming

This lecture opens the Systems Programming course as its foundation stone. It maps the six interlinked modules, explains how evaluation ties to lab work, revisits what a computer really does at the hardware and software boundary, introduces the translator chain that turns human text into running processes, surveys Unix and Linux history and strengths, establishes the file as the universal abstraction, demystifies the shell and commands, walks through the live cloud lab and SSH bastion workflow, and finally puts your hands on the first commands with verification rituals you will reuse all semester.

Every later lecture — file system internals, VI, filters, shell scripting, system calls, assembler/linker/loader — builds on the mental model you form here, so treat this preamble as the index you will keep returning to.

1.1 Course Roadmap — Six Interlinked Modules, Objectives and Learning Outcomes

1.1.1 Foundational Position of the Course

This course acts as a very basic, foundational course for any other course on the system side. Network programming, cloud computing and edge computing all assume comfort with the underlying system. The ability to run commands, combine them into scripts and understand how system applications actually work under the hood is the common base. The focus is on what goes on inside the system rather than on surface-level use. By the end, you can work on a Linux system with confidence and you can combine multiple tasks into one automated workflow.

The professor framed the goal in one plain line: by the end you will do two things comfortably — work on a Linux system without hesitation, and combine multiple tasks into one automated workflow. That second ability is exactly what industry calls automation, and it is the thread that ties all six modules together.

Visual intuition: picture a horizontal spine with six blocks left to right, each block feeding the next. Block 1 (basics and organization) shows a filing cabinet; Block 2 (inode internals) zooms into a single drawer mechanism; Block 3 (VI/filters) shows scissors and pipes joining cabinet contents; Block 4 (shell scripting) shows a factory assembly line combining previous tools; Block 5 (system calls/processes) shows a C program knocking on a kernel door; Block 6 (assembler/linker/loader) shows that door opening into RAM execution. The takeaway: you move from what you see (files) to how it works inside (inodes, processes, loaders).

1.1.2 The Six Modules in Order

There are six modules that are linked to one another and each plays an important role:

Module 1 — Linux basics and the file system. How directories and files are placed, the overall file system as a whole, and the various basic Unix commands for files and directories. This gives insight into organization and into the different command families that exist.

Module 2 — Internals of the Unix file system. How the i-node is actually done in Unix, how information is stored and how a file is accessed. This explains what the file system does when you create a file or a directory.

Module 3 — The VI editor, files, directories and filters. The VI editor, the different commands, the modes it works in, plus commands for files and directories and the different filters that can be employed.

Module 4 — Shell scripting. The most important module among all. Shell scripting combines many commands together with programming constructs to form a unique activity or a specific task. Your assignment is mostly on shell scripting. This module brings together commands and constructs such as for loops, while loops and if statements to build scripts that group multiple tasks into one.

Module 5 — System calls and processes. What a system call is, what its purpose is, how to create a process, what a process is, how it looks different from any other process, and how system calls work when used from a simple C program. The examples are kept very simple — often a single file with a few system calls — so attention stays on what goes on inside the program rather than on elaborate C construction. No need to create multiple functions or complex program structure for these demonstrations.

Module 6 — Assembler, linker and loader. Why these three different system software programs are important, how an assembler works on code, how linkers and loaders are built, what different steps are involved in building them, and how they work in practice. Assemblers are often combined with interpreters and with compilers. You do not need to become an assembly language programmer to understand this, but you do need to understand how an assembler translates assembly language. Linkers and loaders on the other hand have direct impact on execution because they interact with the brain of the system — the operating system — to change a program from state program to state process.

# users.txt:  alice:pass123:1001:1001:developers:/home/alice:/bin/bash  (one per line)
while IFS=: read -r user pass uid gid grp home shell; do
    echo "Creating \$user ..."
    sudo adduser --uid "\$uid" --gid "\$gid" --home "\$home" --shell "\$shell" "\$user"
    echo "\$user:\$pass" | sudo chpasswd
    sudo usermod -aG "\$grp" "\$user"
done < users.txt

1.1.3 Objectives Framed as Capabilities

First, understand the file system, the directories and the files under the file system as a whole, including how they are organized and how that organization creates the need for a file system. Then gain insight into the different types of commands that exist and how you can come up with scripts which combine multiple commands to form a specific task. Next, understand the purpose of system calls and how they behave when driven from C. Finally, understand assemblers, linkers and loaders, what they do and why linkers and loaders are required to help a program execute.

In capability language:

1. Explain organization — why $/$ must exist, why $/bin$, $/boot$, $/dev$, $/home$, $/usr$ are separated, and what breaks when you mix them.
2. Combine commands into tasks — select the right filter or file command for each sub-step and wire them with pipes, loops, and tests.
3. Drive the kernel from C — issue a system call and observe the process that results, describing its state and identity.
4. Account for translation to execution — narrate the path text → object file → linked image → loaded process, naming who does each step.

These four verbs — explain, combine, drive, account — are what examiners will ask you to demonstrate, not just define.

1.1.4 Learning Outcomes — What You Can Do Later

Six months or a year after finishing, you will have a good understanding of all Unix commands, the shell, processes and other required commands. You will be able to write shell scripts — not just simple ones but good scripts — because your assignment will force you to understand and to write. You will understand the Unix file system, the way it stores information and how information is accessed from a file. You will understand the shape a process takes while it is running and the working of the assembler, linker and loader.

Think of this as durability: the lecture promised outcomes that survive six to twelve months because they are practiced, not memorized.

• File system durability: you can stat a file, read its inode number, and explain which blocks hold its data — not just say "it is stored somewhere."
• Scripting durability: you can write a good script — with argument handling, error checks, and comments — not just a one-liner that works once.
• Process durability: you can draw the process image (code, data, stack, heap) and point to where the loader placed each piece.
• Translator durability: you can state, for any given build, which step would fail if a symbol were undefined and whether the fix belongs in assembler, linker, or loader.

1.2 Textbooks, References and How to Use Them

1.2.1 Core Textbooks

Three core books are used:

Kernighan and Ritchie — C programming language classic. For a first-time user it looks a little tricky, but it gives a lot of information about the Unix environment. It is a wonderful book for the early Unix perspective.

Sumitabha Das, Unix Concepts and Applications — Wonderful coverage in depth and in breadth. It covers a lot of things and is a strong main reference for Unix concepts.

Richard Blum and Christine Bresnahan, Linux Command Line and Shell Scripting Bible — A good book to understand the command line and shell scripting. Useful when you want practical command and scripting detail.

You can buy hard copies and build a small library, or use legally obtained ebooks. PDF versions are said to be available for free from various sites, but for academic purposes the recommendation is to use a hard copy or a legally obtained ebook. Ebooks are an option and add to the books you already have.

1.2.2 Broader Reference List

A long list of reference books is provided in the handout. You do not need all of them. At least the book that covers system software is valuable when you reach the last module, because the linker and loader are discussed there. The handout also describes what it consists of — syllabus, evaluation components and activities.

The handout is itself an important companion document: it contains the syllabus topic list, the evaluation split (EC1/EC2/EC3), and the activity plan. Treat the long reference list inside it as a menu, not a mandate. Your selection rule is simple:

• Before Module 3: Das + Blum for commands, filters, VI.
• Module 5 onward: add a systems-programming or advanced Unix reference that treats processes and system calls precisely (e.g., the APUE-style family represented in companion docs R5/R6).
• Module 6: add a system software book that treats assembler, linker, and loader as distinct build steps with diagrams — this is the one the professor explicitly said "at least get."

You do not need to buy all. A focused shelf of 4–5 books you actually annotate beats a shelf of 20 you never open.

1.2.3 Suggested Study Approach

Go breadth-first for the overview, then depth-first for shell scripting and file system internals. When a textbook chapter is mentioned, read it in full. For system software, read the compiler, assembler, linker and loader sections with attention to steps and rationale. Use man pages and trial on the live system to test each command as you learn it.

Visual intuition: imagine a map of a city. Breadth-first is flying over it to see all neighborhoods; depth-first is walking two neighborhoods street by street because you will need to give directions there under exam pressure. Both are needed, but breadth must come first or you memorize streets without knowing which neighborhood they belong to.

1.3 Evaluation Architecture and Assignment Integrity

1.3.1 Component Weights and Syllabus Coverage

Evaluation is split into EC1, EC2 and EC3. Exam note: EC1 consists of quiz and assignment. Quiz one plus quiz two plus assignment put together is on the higher side when compared with EC2, which is the midterm exam. Exam note: EC1 weight covers quizzes and the lab assignment. Exam note: EC2 is the midterm, 30 marks, open book, conducted online, covering topics up to that point. Exam note: EC3 is the end semester exam, 40 percent, open book, conducted online, covering all topics in all modules. EC3 therefore is the full syllabus for the final open-book exam.

1.3.2 Quizzes — Format and Window

Exam note: Expect multiple choice questions for quiz one and quiz two. Each quiz is online with a specific time window within which you must complete it. The quiz stays open for at least two to three days, maximum three days. Within that window, once you start the quiz you must finish it in one attempt in the allowed time. There are no multiple attempts. Dates and times for quiz one, quiz two and assignment will be announced well in advance. This window is intentionally bigger than a narrow slot like 9:00 to 9:30 at night.

1.3.3 Assignment — Scope and Presentation

Exam note: Assignment is for 20 percent and directly maps to the lab component that runs across the ten or eleven contact sessions. Every contact session includes some lab component, and the set of exercises there becomes the assignment. The assignment task is of a somewhat complex nature, similar to the lab exercises, because there is much to gain. Exam note: Assignment will be a group assignment of two or three members. Groups are formed by you. Very soon the group size will be confirmed. After submission you cannot just submit and forget. You must complete the task and do a presentation of your solution.

Real-world: Assignment is where shell scripting competence is built. The assignment will make you understand scripts, write scripts and move beyond simple one-liners to good scripts that combine many commands and program logic.

1.3.4 Academic Integrity, Originality and Deadlines

Just changing a color or a tiny detail does not make code different. Underlying code can still be identical. Copycats will be caught and will be punished. If copying is found, you receive zero marks. Originality is required. Being found guilty leads to penalty.

Exam note: Do not miss deadlines when they are given. When asked to submit on a specific deadline, you need to submit on that deadline. Enough time will be given to complete assignments, but not too much time — just enough to submit in a timely fashion. As working professionals you have busy days and free days. Since you chose this program, give it the time it needs and complete the required formative work with the same intention with which you joined.

1.3.5 Contact, Help and Calendar

If you have questions, difficulties or need clarifications, post in the discussion forum rather than writing directly. The forum reaches a wider audience and peer participation is encouraged because a few learners already have working knowledge of Linux and Unix and can share experience. Group learning over discussion forums is encouraged. The course runs in flip mode and you already have access to recorded content. The calendar in the team system had shown classes even on Sundays and on exam days where no contact session was scheduled. That is being rectified and a proper schedule that maps only days with contact sessions will appear. This first contact session is one of nine or ten planned contact sessions.

1.4 Computing Foundations — PSM, Control and the Software Stack

1.4.1 The Computer as PSM Plus Control

A computer is a capable machine that can do three things and needs a fourth to keep order:

Process data — To process data you need a program. The program runs, consumes data, changes its form in various ways and provides a result.

Store data — In memory storages, both temporary and permanent. The system provides capability for both.

Move data — From input and output devices, to display, over the network to another device, to and from peripherals. Moving data involves I/O peripherals.

Control — Without control the above three would be chaotic. The system has only one set of address lines and one set of data lines. You cannot do a read and a write on the same data lines in the same clock cycle. If a program says read this and write this and those run in two separate threads using the processor without coordination, I/O systems and data lines become confused and the system falls into chaos. Control streamlines some tasks to run in sequence and plans others to run in parallel. A control unit helps executing programs in the form of processes that consume data in a neat way.

In short, remember PSM of data — processing, storing, moving — plus control.

Visual intuition: draw two timelines. Top timeline (without control) shows Program A "READ x" and Program B "WRITE y" overlapping the same bus slot — red collision band. Bottom timeline (with control) shows A's READ in cycle 1, B's WRITE in cycle 2, I/O DMA in cycle 3, with a small scheduler box deciding who goes next. The one-sentence takeaway: concurrency without control is collision; control turns contention into orderly sharing.

1.4.2 Applications and Programs You Meet First

As an end user you probably use a text editor, a remote connection tool, a compiler front end, a database or you run queries. These are different applications or system programs that the end user interacts with directly. You do not interact with the kernel or the hardware every time. Applications work with the operating system, and the operating system works with the hardware to get the job done.

Think of a familiar stack: you type in VI or VS Code, push via SSH, compile with gcc, query a database. In each case your hands touch an application or system program; that program then asks the operating system to allocate memory, schedule CPU, and drive devices. You rarely bypass the OS to poke hardware — and on a managed system you are not allowed to.

This layering is why systems programming spends so much time on the mediator — the system software that lets endless applications share one set of hardware safely.

1.4.3 System Software Versus Application Software

There are two types of software:

Application software — Used or designed to be used by the end user. The list is endless.

System software — Helps the computer run the application programs. Designed to run on the hardware and to help application programs run. The set is very limited.

Examples of system software are an operating system, a compiler which acts as a translator from high-level language to machine level language, and an assembler which translates assembly language to machine level language. Machine level language is what the machine can understand. A machine is not universal. It understands a limited set of instructions, perhaps around 15, 16, 200, 250 or 256 instructions. Everything you write must boil down to one of those instructions.

A common slip is to call the compiler target a middle level language. The correct target discussed here is machine level language. That correction matters because the hardware only responds to its instruction set.

Real-world: 8085, 8086, PDP-11 and PDP-12 were well known assembly targets in engineering curricula. Assembler translates that assembly to machine code the machine can understand.

1.4.4 Where System Software Sits

Think of layers. Outermost is the end user. Next is applications and system programs the user touches. Then the operating system as mediator. Innermost is hardware. System software is the narrow layer that talks to hardware on behalf of everything else.

Visual intuition: concentric rectangles. Outermost: End user. Next ring in: Applications & system programs (editors, compilers you invoke). Next: Operating system — the only ring with drivers that can touch CPU, memory, buses. Center: Hardware (CPU, RAM, disks, NICs). Arrows go user → application → OS → hardware and back. The takeaway: all roads to hardware go through system software — which is why bugs or bottlenecks there affect everything above.

1.5 Translators in Depth — Compiler, Assembler, Linker and Loader

1.5.1 Compiler

A compiler — a program that translates a high-level language such as C, C++ or Java into machine level language — reduces abstraction to the instruction set the hardware supports. Because the instruction set is small, all high-level constructs must reduce to that set. A compiler combines with other translators in real toolchains but is conceptually distinct from an assembler.

1.5.2 Assembler

An assembler — a translator from assembly language to machine language — does not work from a high-level language. If you want to use an assembler as is, you need assembly language programming. In this course you will not get into full assembly language programming, but you will understand how the assembler works on any code. Assemblers are sometimes seen combined with interpreters and sometimes with compilers in explanations. That combination view is used to show why understanding assembler matters even if you do not write assembly day to day.

1.5.3 Linker and Loader — Turning a Program into a Process

The linker and loader are very important because they interact with the brain of the system, which is the operating system, to make a process change state from program to process. You require the help of the linker and the help of the loader for a program to execute. Understanding how linkers and loaders are built, what different steps are involved in building them, and how they work is a core goal. This explains how a file that contains data and control structures created by users, compiled via compilers into executable form, actually reaches execution as a running process.

Think of it as steps with rationale: translation to machine form, linking to resolve references across pieces, and loading to place the result in memory under operating system control so it can run as a process. Not every part of the operating system can work with hardware directly. Only device drivers can drive CPU, memory and buses. Drivers accept requests and make devices work for running programs. Coordination among drivers is part of what makes execution orderly.

Visual intuition: picture an architect's workflow. Compiler/assembler produce blueprints of individual floors (object files). Linker is the structural engineer who aligns floors, resolves where the staircase connects floor 2 to floor 3 (symbol resolution), and produces one buildable set. Loader is the site crew that pours the foundation at a specific plot (memory addresses), hoists the building, and connects power/water (drivers). The takeaway: drawings alone are not a building — linking makes them coherent, loading makes them inhabitable.

1.6 Unix and Linux — History, Architecture and Kernel Services

1.6.1 Unix and Linux Used Interchangeably Here

For this course Unix and Linux are used interchangeably and treated as equivalent operating systems for many purposes. Unix is closed source and not open source like Linux. It was developed in 1969 by Thompson, Ritchie, McIlroy and others. In 1973 Ritchie and Thompson, inventors of C, rewrote Unix in C. Linux in many ways is considered a successor of Unix and was developed by Stallman and Torvalds.

1.6.2 The Unix Structure Diagram — Layers

The basic figure for Unix has four bands: outermost end users, then a shell that acts as an interface between user and kernel, then the kernel which is part of the operating system, then hardware that the kernel talks to. The shell and the kernel have distinct responsibilities.

Visual intuition: four concentric bands, outermost to innermost:

• Band 1 (outer) — End users at terminals.
• Band 2 — Shell (Bourne-family $\$$, C-family , or root $\#$ prompts) — the command interpreter you type to. It checks syntax, expands wildcards, and asks the kernel to act.
• Band 3 — Kernel (part of the OS, always resident) — file, process, memory, I/O, accounting, interrupts.
• Band 4 (center) — Hardware — CPU, RAM, disks, NICs, driven only via drivers.

Arrows: users never reach hardware directly; they go through shell → kernel → drivers → hardware, and results flow back the same way. One-sentence takeaway: shell translates intent, kernel enforces policy and drives hardware.

This diagram is the map you will use to answer "where does this happen?" — e.g., "ls is a program invoked via the shell; fork() is a kernel service."

1.6.3 What the Kernel Is and What It Is Not

A kernel — the important piece of the operating system that keeps running at all times when the computer is on — is not a separate category of software beyond system versus application. The operating system is system software, and the kernel is a very important module of the operating system. It is system software and is not application software because the end user does not directly use it. Coordination among device drivers happens here. When a system starts, the operating system is installed on the hard disk. There could be multiple operating systems installed. On power-up a check is needed to see that hardware is working and to point to the right block or sector where the operating system resides. This is done by the bootstrap program, the very first program that runs when you boot. It does a system check, confirms things are working, points to the block or sector where the operating system lives and loads that operating system into RAM to start executing it.

1.6.4 Kernel Services in Daily Operation

Key kernel capabilities: file management and security for all production purposes including services for input and output devices; process scheduling and management to avoid conflicts when processes need a device or need to be scheduled or preempted; system accounting including what kind of users are created and how to restrict each user to a specific set of places or directories; memory management including how linkers and loaders help with memory handling and how to avoid page conflicts; interrupt and error handling; and date and time services, which are very minimal. These are the services that let multiple users and multiple programs share one machine.

Visual intuition: imagine a hotel manager (kernel) with six desks: Front Desk (files), Concierge (processes), Accounts (accounting), Housekeeping (memory), Maintenance (interrupts/errors), Clock (time). Every guest (process) must pass through a desk to get a room (memory), a key (file descriptor), or room service (device). The takeaway: sharing one machine among many guests requires a coordinated desk, not just rooms.

1.7 Defining Unix Strengths — Multiprogramming, Time Sharing, Portability, Modularity, Security and More

1.7.1 Multiprogramming, Multi-User and Time Sharing

Features that stood out when no other operating system showed them were multiprogramming, multi-user and time sharing. Multiprogramming means the system can run multiple programs at the same time in the sense that several programs are resident and making progress. Time sharing means those programs take turns on the CPU so quickly that each user feels theirs is the only one running. A classic example is a client-server with one hundred end users connected to a server. Each connection runs as a different process. Each process is scheduled for a certain amount of time and each gets responses quickly. Handling of thousands of processes can be seamless and smooth — provided the CPU is capable enough to meet the heavy requirement and the bandwidth is there. You cannot expect an 8085 processor to host a Linux system for a thousand remote users. You need a capable processor and adequate network support for these features to stand out.

Time sharing works like this. Take a duration of one minute where the CPU works and six processes are ready. Each of the six gets ten seconds in turn. The first ten seconds go to the first process, the next ten to the second and so on. At the end of the six, the cycle forms a round robin and returns to the first process. This is so fast that the different users do not perceive that a single CPU is running all six. It is not truly parallel on a single processor, but in the larger picture it feels like parallelism. That felt parallelism is the core intuition for time sharing.

Multitasking is related but broader. There can be multiple tasks at the same time within a workload. Example with a word processor: typing is consumed and displayed at the same time, the word processor does auto save at intervals, spell check runs as you type and grammar check also runs. Those are different tasks, all active and sharing time to do the job. Another close question is multithreading. A process can have multiple threads within it running in parallel, and those threads can also be time shared. Time sharing at process level and at thread level share the same idea of slicing time.

1.7.2 Portability

Portability — ability to move the system to different hardware with small changes — was key. At that time the main target was x86. Today ARM is also present, though not always prominent among Unix or Linux users. The M1 machine from Apple is basically ARM-based. You can port a Unix or Linux operating system to a different architecture with small changes. That is how it was built.

Real-world: Apple M1 ARM is used as an example that porting is not theory. The same operating system ideas with small changes run on a different instruction set.

The causal link is the 1973 C rewrite (see 1.6.1): a kernel in C is hardware-shaped only at a narrow seam (boot, page tables, drivers). Replace that seam, recompile, and you run on x86 or ARM. The M1 is the modern anchor — an ARM core running a Unix-descended OS with the same file, process, and shell abstractions you will use on x86 Ubuntu in the lab.

Visual intuition: two engine bays (x86 and ARM) with different bolt patterns, but the same engine block (kernel in C) fits both with a different mounting plate (machine-dependent layer). The takeaway: portability is not magic — it is C plus a thin abstraction layer.

1.7.3 Modularity

Modularity — building as pluggable modules rather than one monolithic block from first line to last — lets tasks and activities be split into different modules that can be extended to do multiple things. That growth model explains how the system keeps adding capabilities without rewriting everything.

Think plugin, not rewrite. A new file system type, a new scheduler policy, or a new device class arrives as a module that plugs into well-defined interfaces. Without modularity, each addition would require editing a single giant monolithic file from line one — brittle and unreviewable. With modularity, teams extend the system concurrently.

1.7.4 Security

Security — layered access — is pretty good and pretty tight in Linux and Unix compared with early Windows, which was slow to cope with security. Different levels are in place: user level permissions, group level and system level. Access permissions are given to files and directories at those levels. File structure and security are linked, which leads directly to the file abstraction.

Unix security is file-centric, which is why it leads naturally to 1.8's "everything is a file":

• User level: owner bits ($rwx$ for $u$) — what you can do to your file.
• Group level: group bits ($rwx$ for $g$) — what your team can do.
• System/other level: other/world bits ($rwx$ for $o$) plus superuser — what everyone else can do.

Permissions are file metadata (stored in the inode), and directories are files that list what lives inside them, so access control on files automatically controls the namespace. Device files being files means the same permission check that gates a document also gates a printer — uniformity is a security feature.

1.7.5 Device Independence, Communication, Tools and Compilers

Device independence means you need a driver to run a device, but once you have it the job is done. The story told for context is installing Linux on a Zenith academic machine around 1999 or 2000. Fedora 1 or Fedora 2 took about eight or nine installations before one succeeded. Every driver had to be chosen for what was in the hardware: processor kind, memory size, display, keyboard, mouse with two or three keys and a scroll, and so on. None of that was taken automatically then. These days even young users use computers running Linux without noticing a difference. Communication is strong. Using various protocols, the system supports tools and services like FTP, Telnet and SSH. Compilers are plenty: C, C++, and if something is not there you can install it. Other tools such as grep are also present. Almost seventy to seventy-five percent of servers in the server world still lean on Linux or Unix machines because of all these capabilities.

1.7.6 Why Linux Is Popular — Free, Open, Customizable, Proven

Linux popularity rests on several linked points:

Free and open source. Anyone has the freedom to work on the code. Open here does not mean everybody edits the mainline at will. It means the option exists and the code can be worked on and evolved.

Evolves to support many machines. Because it is open it has grown to support different machines and to add features quickly.

Supports protocols and devices. It supports various protocols and various devices for wireless connectivity and similar needs. Say Wi-Fi 6 comes to market in some year or month. A company working on Wi-Fi 6 can pick up the Linux code, add a module for Wi-Fi 6 to work, test it and once it works it will be rolled out in the standard edition. That speed comes from openness.

Customizable. You can tune the system to your needs. You can install without a UI by checking it off or with a UI. You can leave out a set of tools that you do not want. Customization explains how Linux was ported even to constrained devices.

Constrained devices and Android. Porting to constrained devices is a direct result. Android built on the Linux kernel is used in smartphones we carry daily.

Real-world: Open source does not mean chaotic edits. It means a Wi-Fi 6 vendor can develop a module against the open code and, after testing, the feature enters the standard edition.

Real-world: Android is the everyday proof of customization and portability. The phone in your hand runs a system built on the Linux kernel.

1.7.7 Distributions

There is a very limited list of Linux distributions shown as flavors in the market, with at least ten to fifteen more that are very popular beyond them. Names mentioned include Debian, Fedora, Ubuntu and CentOS, plus special ones such as Kali Linux or Parrot OS which carry tools for testing, hacking and vulnerability checking. Beyond those, many others exist.

Think of distributions as curated bundles of the same kernel and tool heritage, differing by package selection, release cadence, and target audience:

• General — Debian, Fedora, Ubuntu, CentOS: different packaging (DEB vs RPM), different stability vs freshness trade-offs, but all share the Unix/Linux core you are learning.
• Specialist — Kali Linux, Parrot OS: pre-loaded with security testing, hacking, and vulnerability-check tools so testers do not assemble them by hand.
• Long tail — 10–15+ more popular: the lecture noted the displayed list was limited — the ecosystem is larger than the slide.

Visual intuition: a base chassis (kernel + GNU tools) with different trim packages — commuter, off-road, racer. The chassis is shared; the trim (distribution) chooses which tools ride along.

1.8 The File Principle — Everything Is a File, Types and Hierarchical Layout

1.8.1 Everything Is a File

In Unix or Linux everything is considered as a file. Hardware such as memory or I/O devices, when you want to write to the display you write into the file and that in turn writes to the display. Anything and everything in this environment is a file in the sense of a named entity the system manages uniformly. If it is running, it will be a process. A file fundamentally consists of some data and some control structures. Files are created by users and compilers are used to compile program text into executable form and run them as executables.

Visual intuition: draw / at top, branching to regular files (leaves), directory files (branch nodes that contain lists of leaves), and device files (leaves that are portals to hardware behind the tree). One-sentence takeaway: the tree looks uniform from above, even though some leaves are portals.

1.8.2 Three Categories of Files

Unix files are in three categories:

Ordinary file — A regular file that contains a stream of alphanumeric characters or more generally a stream of data. Documents, text files, spreadsheets, C files, Java files, Pascal files and machine code files after translation all fall here.

Directory file — Contains details of what files and subdirectories are there within that particular file. It is the map of containment.

Device file — Represents devices. Block devices such as memory and hard disk where data moves in blocks, and character devices such as a printer where data moves as a sequential stream to be printed. All these devices are represented as files.

Thinking of hardware as files is not a metaphor for convenience. It lets the same tools and permissions apply to both data and devices.

1.8.3 Grouping into a Hierarchy

Files are grouped into directories and those form a hierarchical structure. Everything points to one main directory called root indicated by a slash $/$. Under root you have multiple folders, generally named bin where executables are, boot where certain boot related files are present, dev for device files, home, root and usr, plus others. In home you have details of all the users and within each user you have desktop or download and other files for that user. Within that you can have your own files. The description of home as holding per-user directories matches what you see live: $/home$ contains entries for each created user.

Example: The live system shows $/home$ holds directories for each numeric ID such as 190242501 through 529 and a directory ubuntu for the demo user. Each new user such as ABC also gets a directory under $/home$ after successful creation.

 /                  ← root, the single parent of everything
 ├─ /bin            ← essential executables (ls, cat, cp)
 ├─ /boot           ← boot loader, kernel images
 ├─ /dev            ← device portals (sda, tty, lp)
 ├─ /home           ← per-user homes (see below)
 │   ├─ ubuntu      ← demo user (present on lab)
 │   ├─ 190242501 … 190242529  ← cohort numeric IDs
 │   └─ ABC         ← example newly created user (after sudo adduser ABC)
 ├─ /root           ← root user's home (distinct from /)
 └─ /usr            ← secondary hierarchy (libraries, docs, more binaries)

ubuntu  190242501  190242502  ...  190242529

ABC  ubuntu  190242501  ...  190242529

Visual intuition: imagine a paper filing system: $/$ is the cabinet, each top-level folder is a drawer ($bin$ = tools drawer, $dev$ = cables drawer, $home$ = employee pigeonholes). Opening the $home$ drawer reveals one labeled folder per employee — each folder is that employee's desk surface where their personal files live. Takeaway: the cabinet's structure is what makes finding any file a path-tracing problem, not a search.

1.8.4 Files and Their Compiled Companions

Program sources such as C, Java and Pascal are program texts you write because it is not feasible to write directly in machine code. The high-level text is written for humans and then translated via compilers and related tools into machine code files that the hardware can run. That is why the file idea links to executables in $/bin$ and to your own binaries.

Every program begins as an ordinary file of text — hello.c, Main.java, prog.pas — human-readable precisely because files impose no structure. That text lives in the hierarchy (often under your home), is edited via a file editor (VI in Module 3), and is translated via compilers/assemblers into another ordinary file of machine bytes — e.g., a.out or hello — which the loader can place in RAM as a process. The executables you already use under /bin (like ls and cat themselves) are just such translated files, preinstalled.

1.9 Commands Demystified — Shell, Prompts, Internal Versus External and Path Search

1.9.1 Shell as Command Line Interpreter

A shell — a command line interpreter that sits between user and kernel — is the command line interface. It is the one who interprets commands given by the user. When you give a command, the shell does syntax checking. You cannot give anything you like and expect the system to understand. There is no AI operating system yet where you say DAT and it accepts it as CAT. At least today we do not have that. Alexa is kind of like an assistant but not an operating system; it is an application running on top of the operating system. So DAT will be flagged as an error. The shell understands what is given as a command, interprets it and helps produce the output.

Visual intuition: a flow diagram with you on the left, shell in the middle, kernel+drivers on the right. Input cat /etc/passwd flows left→shell→kernel→disk driver→bytes back via kernel→shell→terminal. Input DAT stops at the shell with a red X and command not found. Takeaway: every command touches the shell first, even if it ends at the kernel.

1.9.2 Prompts and Shell Families

Different prompts signal different contexts and shell families. A dollar $\$$ or a pound $\#$ or a percent $\%$ may appear, depending on kind of user and shell. The root user has one type. The Bourne shell, Bourne Again Shell $\text{bash}$, Korn shell $\text{ksh}$ and Z Shell $\text{zsh}$ use $\$$ as prompt. The C shell and TC shell use $\%$. Root uses $\#$ as prompt. When commands are typed, the shell searches the predefined path where commands exist as executable files and helps execute that command.

1.9.3 What a Command Is

A command — a program defined to do one particular function — is generally written in C and invoked through the shell. It could be $\text{ls}$ which lists files and directories, or $\text{grep}$ or $\text{cat}$ or similar. Each is a program that executes and gives the required output.

Strip it to essentials: a command is a program (file of machine bytes under e.g., /bin/ls or /usr/bin/grep) plus a name the shell recognizes, doing one thing. Most were written in C for portability and direct access to system calls, which is why K&R remains a relevant companion text.

The Unix habit of "one tool, one job" (e.g., ls only lists, cat only concatenates/displays, grep only filters) is what makes shell composition powerful — you later join these single-purpose programs with pipes and scripts rather than building monolithic tools.

1.9.4 Internal Versus External

Unix or Linux commands are in two categories:

Internal command — Part of the shell itself. It works as part of the shell process. The shell does not have to search for a path because it is not stored as a separate executable elsewhere. It does not start a new program to execute. Examples are $\text{echo}$ and $\text{pwd}$. The shell does not search for these.

External command — Exists as an executable in a specific place. You need to find where its executable is present and that executable will be executed to give output. Examples are $\text{grep}$ and $\text{cat}$ and similar tools where executables live in a known place and you must find and execute them.

The classroom test of this was to ask without Googling what the difference is between internal and external commands in the Linux shell. The intuition to keep is path search versus built-in. Internal needs no search. External requires finding the executable path and then executing.

1.10 Lab in Practice — 24x7 Cloud Host, SSH Bastion Workflow and User Management

1.10.1 The Lab You Will Use

A Linux machine has been installed in a cloud environment so work is in one place together. This machine is up 24 by 7. You can connect at any time of day or night. Absolutely no problem. Be professional: do not wander, delete or disturb the work of others. This host is shared. The image is Ubuntu for the inner lab, fronted by a CentOS bastion. That two-step shape is intentional.

1.10.2 Tooling — PuTTY and Native SSH

In order to connect you need a tool like PuTTY. PuTTY is a small installed tool. Likewise there are many other tools that can give SSH connection to remote servers. You can also use SSH directly from the command line if you are on an Ubuntu machine where SSH is installed. Both paths reach the same host. If you have a local Linux you do not have to install inside the lab to practice locally, but doing work on the shared machine keeps all work together.

Real-world: PuTTY on Windows and $\text{ssh}$ on Linux or macOS both speak SSH to the same public endpoint. Choose what your station already has.

1.10.3 Step-by-Step Bastion Login

Address: public IP $\mathrm{125.17.103.123}$, port $22$, protocol SSH.

Using PuTTY: install PuTTY, open session, paste the IP $\mathrm{125.17.103.123}$, set port $22$ and select SSH and click Open. For readability you may go to Appearance and change font size from 10 to 14 before opening. You will be prompted for a username. For the first machine — the bastion host — the username is $\text{centos}$ and the password is $\text{ADMIN@\#2022}$ — spoken as ADMIN at hash two zero two two, shown in class as $\text{ADMIN@\$2022}$ and $\text{ADMIN@\#2022}$ variants meaning the same account —. After login you will see a dollar prompt $\$$ indicating a normal Bourne-family shell and you can type $\text{ls}$.

Using native SSH from Ubuntu: run $\text{ssh centos@125.17.103.123}$. You will be asked for the password; give $\text{ADMIN@\#2022}$. You will see the same dollar prompt and you can type $\text{ls}$.

Expected outcome after $\text{ls}$ on the bastion: you see $\text{connect.sh}$ as the script that bridges to the inner lab.

Exam note: The inner lab is not reached by repeating $\text{ubuntu}$ at the first prompt. $\text{ubuntu}$ at the first machine will not work. Use $\text{centos}$ first, then bridge.

ssh centos@125.17.103.123
# password: ADMIN@#2022
[centos@bastion ~]\$ ls
connect.sh

1.10.4 Bridging to Your Personal Ubuntu with connect.sh

Once on the bastion you run $\text{./connect.sh}$ followed by your BITS ID, for example $\text{./connect.sh 502}$ or whatever your first part of mail ID or BITS ID is. Then you are asked for a password. For every user the password for this second step is $\text{ubuntu}$ written as U-B-U-N-T-U. After that you are logged in with your own username such as 502, 506, 510, 508, 515 or 520 and others up to the 529 range. The live demo showed 1, 2, 3, 4, 5 users logging in apart from the demo user, and counts like 5 users apart from me increasing as more joined. You will not see the same folder listing as the demo user because each account lands in its own home. From $\text{ls}$ inside, experience shows you land in your own space.

Concrete detail: On the bastion, $\text{ls}$ shows $\text{connect.sh}$. Inside, after bridging, $\text{ls}$ behavior differs per user because home is per-user. The shared pool shows $/home$ contains entries like $\text{ubuntu}$ for the demo and $502$ through $529$ for the cohort.

Troubleshooting noted in class:

• $\text{connect.sh}$ throwing error — Say what the error is. Example of confusion: trying $\text{ssh ubuntu@125.17.103.123}$ for the bastion or forgetting to give the BITS ID as argument to $\text{./connect.sh}$. The fix is exactly $\text{./connect.sh}$ plus your BITS ID, then password $\text{ubuntu}$. Example given in class: $\text{./connect.sh 502}$ style. Do not mix IDs.
• Multiple tools confusion — Putty appearance versus SSH command line look different, but both end at the same dollar prompt and both lead to $\text{connect.sh}$.

Real-world: Bastion hosts are common in industry. You SSH to a hardened entry point and from there reach internal machines. The pattern protects internal VMs while giving one public address.

[centos@bastion ~]\$ ./connect.sh 502
Password: ubuntu          # literally type ubuntu, no echo
[502@lab ~]\$               # now your personal Ubuntu
[502@lab ~]\$ ls
# your own home contents — different from demo's ubuntu listing
[502@lab ~]\$ whoami
502

Visual intuition: a building lobby (bastion, guard asks for CentOS badge) → elevator script connect.sh that needs your room number (BITS ID) → private room (Ubuntu VM) where the key is always ubuntu. Lobby is shared; rooms are private. Takeaway: one public door, many private homes.

1.10.5 User Accounting — Who Is Logged In

You can see who is logged in. Outputs mentioned include $\text{pts/2}$ style lines. $\text{pts}$ is pseudo terminal slave. The machine reported several pts entries as users joined. The command $\text{who}$ and $\text{who am i}$ family show this. Concrete recall: The demo saw entries for $\text{pts/2}$ etc and a total that grew from one or two users to five plus.

• who — all logged sessions with terminal, login time, and origin.
• who am i / whoami — focused checks (full vs compact — detailed in 1.11.5).

The demo's count growing from 1–2 to 5+ illustrated concurrency: each new ./connect.sh <ID> creates a new pts/N line. You will use this to sanity-check "is anyone else on my account?" and to see your own pts number for write/mail tests later.

1.10.6 Managing Workspaces on the Host Side

If you are on a machine where you used $\text{Control+Alt+F2}$ or $\text{F3}$ and logged in locally, those are different workspaces $\text{TTY2}$, $\text{TTY3}$ with no IP address shown. Type $\text{who}$ to see them. To return to graphical interface press $\text{Control+Alt+F7}$. If stuck, typing $\text{exit}$ logs out of that text workspace, and rebooting will restore GUI if control-alt-f7 does not. In some keyboards you may need the Fn key plus F7.

1.11 First Commands in Action — date, cal, cat, passwd, who and Verification Rituals

1.11.1 date and cal — Time You Can Trust

The date command shows both date and time. The live example gave July 24, which was a Sunday, at 11:57:45 IST 2022. Run $\text{date}$ and you see the same style. This is fundamental and nothing deep to discuss except that it sources system date and time services that the kernel keeps.

The cal command shows the calendar for this month, neatly organized. In the demo it showed July 2022. You can customize:

• $\text{cal}$ or $\text{cal 2022}$ style? The demo used $\text{cal}$ for current month and $\text{cal -m 3}$ to mean month three — January February March — so $\text{cal -m 3}$ prints March of the current year 2022. Adding a year such as $\text{cal -m 3 1975}$ prints March 1975. Similarly $\text{cal -y 1975}$ was used to find the day of birth: running $\text{cal -y 1975}$ shows the full calendar for 1975 and revealed that the demo birth month fell on a Wednesday. Combining month and year such as $\text{cal 3 1975}$ also prints March 1975. The options $\text{-m}$ for month and $\text{-y}$ for year combine: first parameter month, second parameter year.

Worked walk: Suppose you want March 1975 alone. You type $\text{cal 3 1975}$. The system prints the March grid for 1975. If you want the whole year 1975, you type $\text{cal -y 1975}$ and you get twelve month grids that let you look up any day. Students used this to check a birth day and saw Wednesday.

Q: How do I view a calendar for a particular year and month together? A: Combine the options. $\text{cal}$ shows this month. $\text{cal -m 3}$ shows March of this year. $\text{cal 3 1975}$ or $\text{cal -m 3 1975}$ with month first and year second prints that month of that year. $\text{cal -y 1975}$ prints the entire year.

\$ date
Sun Jul 24 11:57:45 IST 2022

\$ cal
     July 2022
Su Mo Tu We Th Fr Sa
                1  2
 3  4  5  6  7  8  9
10 11 12 13 14 15 16
...

\$ cal -m 3
     March 2022
Su Mo Tu We Th Fr Sa
       1  2  3  4  5
...
# month 3, with year defaulting to current (2022)

\$ cal 3 1975
     March 1975
Su Mo Tu We Th Fr Sa
                   1
 2  3  4  5  6  7  8
...
# month=3, year=1975

\$ cal -y 1975
                            1975
      January               February               March
Su Mo Tu We Th Fr Sa  Su Mo Tu We Th Fr Sa  Su Mo Tu We Th Fr Sa
          1  2  3  4                     1                     1
 5  6  7  8  9 10 11   2  3  4  5  6  7  8   2  3  4  5  6  7  8
...
# full 12-month wall; locate your birth date and read weekday → Wednesday for the demo

Visual intuition: date is a single-line digital clock on the wall; cal is a paper desk calendar that can flip by month (-m) or unroll the whole year (-y) on one sheet. One-sentence takeaway: time is a kernel datum, calendars are filtered views of it.

1.11.2 Creating and Inspecting Users — adduser, /home and /etc/passwd

Create one or two users with $\text{adduser}$. Only root or someone in the admin or root group can run it. So you use $\text{sudo adduser}$ and you give a name such as ABC for temporary purpose. The command asks for your sudo password, then says adding user, creating a new group, adding the new user to this group, creating a home directory and copying files, then it asks to set an initial password and asks for full name details which you may skip with enter.

Verification — how to be sure the user really exists. Three checks were discussed, with a warning about the shallow one:

Check one — look at $\text{/home}$ via $\text{ls /home}$. After creation you do $\text{ls /home}$ and you see ABC among the entries alongside ubuntu and numeric IDs. This is quick but not conclusive.

Check two — try to log in. Try $\text{su ABC}$ or $\text{ssh}$ as that user with its password and see that the login succeeds. That was praised as a good check.

Check three — inspect the password file. Use $\text{cat /etc/passwd}$ — spoken in class as slash etc slash password — to display the contents of the file. The password file holds one line per user. The last line after creation is the entry for the newly created user ABC and it shows its home. In class it was noted to use $\text{cat /etc/passwd}$ and you can see the last line is ABC with its home. For now you are asked to follow this by rote; what each field contains and all those file details will be learned later.

Exam note: When verifying a new user, know that creating a folder manually in $\text{/home}$ with name ABC is not the same as creating a user. You can make $\text{/home/ABC}$ by hand with mkdir, but $\text{cat /etc/passwd}$ will not have a line for it. So $\text{ls /home}$ alone cannot prove a user exists. Use login or $\text{/etc/passwd}$ for the real proof.

adding user `ABC' ...
adding new group `ABC' (1006) ...
adding new user `ABC' (1006) with group `ABC' ...
creating home directory `/home/ABC' ...
copying files from `/etc/skel' ...
New password: ******    ← you set initial password
Retype password: ******
Full Name []:           ← Enter to skip
Room Number []:         ← Enter
Work Phone []:          ← Enter
Home Phone []:          ← Enter
Other []:               ← Enter
Is the information correct? [Y/n] Y

\$ sudo adduser ABC
[sudo] password for 502: ******   # your own sudo password
Adding user `ABC' ...
...
Enter new UNIX password: ****
Retype new UNIX password: ****
# press Enter through Full Name prompts

\$ ls /home
ABC  ubuntu  190242501  190242502  ...  502 ... 529
# ABC appears → directory exists — does NOT yet prove user

\$ su ABC
Password: ****
ABC@lab:~\$ whoami
ABC
ABC@lab:~\$ exit
# successful su proves account authenticates

\$ cat /etc/passwd
...
ubuntu:x:1000:1000:Ubuntu:/home/ubuntu:/bin/bash
502:x:1002:1002::/home/502:/bin/bash
ABC:x:1006:1006:,,,:/home/ABC:/bin/bash   ← **last line, proves user exists**

1.11.3 Bulk Creation — From Single adduser to Many at Once

$\text{adduser}$ in the form sim1 sim2 sim3 pattern is for one or two users. For bulk creation there is also a command to create many users at once — discussed as useradd with a file, often called newusers in practice — where you give a text file whose lines are in a set format. Each line lists username, password, user id, group id, group to which the user belongs, path and shell which will open when the user logs in. You pass that file as argument and the command creates many users in no time. The demo noted create three users as example and said create three users when we create a user how do ... but did not execute the bulk path live. The key takeaway is that the file format plus $\text{useradd}$ or $\text{newusers}$ turns a thousand manual steps into one command.

Worked shape of the file, paraphrased from what was shown: each line in the text file has fields such as username, password, user id, group id, group assignment, home path and login shell. Feeding the file to the bulk command creates that many users without typing adduser a thousand times.

# bulk_users.txt — one line per user, colon-separated fields
alice:passAlice:1007:1007:Alice:/home/alice:/bin/bash
bob:passBob:1008:1008:Bob:/home/bob:/bin/bash
carol:passCarol:1009:1009:Carol:/home/carol:/bin/bash
# fields: username : password : UID : GID : GECOS/group comment : home path : shell

sudo newusers bulk_users.txt
# or, on some systems/labs: sudo useradd  ← with file-handling wrapper

alice:alice123:2010:2010:developers:/home/alice:/bin/bash
bob:bob123:2011:2011:developers:/home/bob:/bin/bash
carol:carol123:2012:2012:developers:/home/carol:/bin/bash

\$ cat three.txt
alice:alice123:2010:2010:developers:/home/alice:/bin/bash
...
\$ sudo newusers three.txt
\$ echo \$?
0   # success

\$ ls /home
alice  bob  carol  ubuntu  190242501 ...
\$ cat /etc/passwd | grep -E "alice|bob|carol"
alice:x:2010:2010:developers:/home/alice:/bin/bash
bob:x:2011:2011:developers:/home/bob:/bin/bash
carol:x:2012:2012:developers:/home/carol:/bin/bash
\$ ls -ld /home/alice /home/bob /home/carol
drwxr-xr-x 2 alice alice ... /home/alice
...

1.11.4 cat — Display, Create and Concatenate

The cat command is used to display contents of a file and can also create a file and concatenate two files. Short for concatenate. Use $\text{cat /etc/passwd}$ to see that file. Three uses mentioned: display contents of a file, create the file itself, and concatenate two files. Working example promised for next class. For now you saw $\text{cat /etc/passwd}$ revealing the last line as ABC entry.

\$ cat /etc/passwd | tail -n 5
ubuntu:x:1000:1000::/home/ubuntu:/bin/bash
502:x:1002:1002::/home/502:/bin/bash
529:x:1029:1029::/home/529:/bin/bash
ABC:x:1006:1006:,,,:/home/ABC:/bin/bash   # ← last line, proof

\$ cat > hello.txt
first line
second line
Ctrl+D
\$ cat hello.txt
first line
second line
\$ echo "third" > extra.txt
\$ cat hello.txt extra.txt > combined.txt
\$ cat combined.txt
first line
second line
third

1.11.5 who, whoami, who am i and pts

The family around $\text{who}$ shows who is logged in:

• $\text{who}$ shows all logged sessions.
• $\text{whoami}$ gives compact just the username.
• $\text{who am i}$ gives an expanded line.
• Output lines show $\text{tty}$ for teletype terminal and $\text{pts}$ for pseudo terminal slave. Because everyone connects through pseudo terminals to the virtual machine, you see $\text{pts/0}$, $\text{pts/1}$, $\text{pts/2}$ and so on plus process ids for each remote logged in process. Example recalled: $\text{who am i}$ printing ubuntu for the demo user, while $\text{whoami}$ prints just the name, and $\text{who am i}$ printing more fields.

The difference in who output for local versus remote was highlighted: local TTY logins via $\text{Control+Alt+F2}$ show TTY3 with no IP, while SSH sessions show pts with the internal IP such as 172 dot something for the host and a public IP 125.17.103.123 seen externally.

Q: Why do I see two ubuntu entries in who output? A: One is the local user already logged in on that machine via the host itself. The other is you as a remote user who logged in through SSH. Who shows both. If you look at your own connection it may show 172 dot internal IP of the host, while public IP is different. The TTY line with no IP is the local console. That split explains the duplicate.

\$ who
ubuntu   tty3         2022-07-24 11:00   # local console, no IP (Ctrl+Alt+F3)
ubuntu   pts/0        2022-07-24 11:20  (172.31.5.10)  # remote SSH (internal IP shown)
502      pts/1        2022-07-24 11:25  (125.17.103.123)  # another remote

\$ who am i
502      pts/1        2022-07-24 11:25  (172.31.5.10)

\$ whoami
502

1.11.6 passwd and mail — Small Rituals with Real Effect

Change your own password with $\text{passwd}$ — spoken as P A S S W D at the prompt. It prompts first for current password — for every user that starts as ubuntu — then for new password, then re-enter new password. Keep the password simple so you do not forget, because forgotten passwords mean resets. You must choose a longer password; a short one was shown to be rejected. Do not change passwords for other accounts such as the centos or ubuntu service accounts. Change only your own and test by logging out with $\text{exit}$ and logging again. $\text{exit}$ logs out of the pseudo terminal session.

Mail between users was demoed: type $\text{mail}$ to check mail, or $\text{mail <user>}$ to send, give subject such as hello, type body such as I am sending a mail, then press $\text{Control+D}$ to finish. The demo saw permission denied and no mail for root and need to install mail, so the working of cat for display versus mail for messaging were kept separate.

Real-world: Changing your password immediately after first login and keeping it simple but longer than the minimum is a basic hygiene step that avoids lockouts for everyone.

\$ passwd
Changing password for 502.
Current password: ubuntu      # initial for every inner user
New password: myLab2022!      # must be longer — short is rejected, as demo showed
Retype new password: myLab2022!
passwd: password updated successfully

# Test it:
\$ exit               # logout of pts session
# reconnect: ssh/putty → centos → ./connect.sh 502 → password myLab2022! → success

# Check mail
\$ mail
No mail for 502

# Send mail
\$ mail 510
Subject: hello
I am sending a mail
Ctrl+D          # end-of-transmission, sends

# On 510's session:
\$ mail
From 502  Sun Jul 24 12:10  hello

1.11.7 Lab Etiquette and What Comes Next

The Linux environment will be available 24 by 7. You can log in and continue work at any time. Keep three windows in mind: chat, presentation and the Linux interface. Next class will show the working of cat for creating and concatenating plus follow-on commands. For now practice date, cal, who family, ls on $\text{/home}$ and the adduser verification ritual so you can feel the difference between a directory that happens to have the right name and a user that actually exists in $\text{/etc/passwd}$.

Exam Guidance Summary

Key Industry Applications