Lecture 02 – Unix Fundamentals

Operating Systems & Unix Context

• Operating System (OS) = low-level software that solves low-level problems
  • Device communication, scheduling/running programs, task management
  • Course focus ➜ how higher-level programs can “interfere” with or leverage the OS
• Distinction between “using” an OS vs. “understanding” an OS
  • Analogy: speaking a language vs. mastering its grammar

Why Unix?

• More programmer-friendly & lower-level than Windows / macOS
  • Fewer GUI abstractions → greater control once internals are understood
• Windows/macOS aim at naïve end-users → advanced users hit road-blocks
• Historical & philosophical roots:
  • Small, modular tools that can be combined (pipes, redirection)
  • “Everything is a file” → unified interface, fewer special-case rules

“Everything Is a File”

• Files, directories, executables, devices, even running processes are treated uniformly
• Benefits
  • Standard API → simpler tools, easier composition
  • Consistent permission model and namespace

File System Hierarchy

• Conceptualised as a single rooted tree (root = "/")
• Directories are ordinary files that list other files
• Example absolute path: /home/Bernard = root → home → Bernard

Navigation Fundamentals

• pwd – print working directory (current location)
• ls – list contents of current directory
• cd <dir> – change directory
  • Supports absolute paths (/home/Bernard) and relative paths (../../Projects)
• Special entries present in every directory
  • . – current directory (useful for commands needing an explicit “here” argument)
  • .. – parent directory (cd .. moves up one level)
• Safety trick: cd / teleports to root when lost

File Permissions Model

• Three actor classes
  • User (u) – owner of the file
  • Group (g) – any user in the same group (max 15 groups per user)
  • Other (o) – everyone else
• Three operation types
  • Read (r) – view contents
  • Write (w) – modify contents
  • Execute (x) – treat as a program / enter directory
• Permissions visible via ls -l (first 10 chars)
  • Example -rwxr-xr--
  • 1st char: - = regular file (d would mean directory)
  • Next 3 – user ➜ rwx
  • Next 3 – group ➜ r-x
  • Last 3 – other ➜ r--
• Odd but legal combos: write-only (-w-) or execute-only (--x)

chmod Essentials

• Symbolic mode
  • chmod +x my_script.sh – add execute for all classes
  • chmod u=rw,go=r my_script.sh – set exact rights
  • +/-r, +/-w, +/-x add/remove permissions
• Octal / binary mode (bits: 4=r, 2=w, 1=x)
  • 7 = 4+2+1 = r\,w\,x
  • chmod 755 my_script.sh → user rwx (7), group r-x (5), other r-x (5)
• SVN gotcha: repository preserves mode; after commit you may need delete & re-add to change exec bit. Missing global x ⇒ marker cannot run script ⇒ catastrophic.

The Kernel

• Core program loaded at boot; interfaces directly with CPU, RAM, devices
• Responsibilities
  • File, user, device, and process management
  • Provides system calls apps use to talk to hardware (e.g., mouse coords)
• Even terminals are devices; modern ones are “terminal emulators” (e.g., gnome-terminal)
• Hardware introspection helpers
  • lsblk – block devices (disks, partitions)
  • lspci – PCI devices
  • lsusb – USB devices

Processes & Analogy

• Program = static recipe; Process = the act of cooking it
• OS (chef) can run multiple recipes simultaneously → multitasking
• Parent/child relationship
  • Child dies if parent dies (default) but can be re-parented (e.g., nohup)
• Each process owns a UID (user ID)

The Shell

• A user-facing process whose purpose is to launch/manage other processes interactively
• Killing parent terminal usually kills children (gedit &, then closing terminal)
• Can switch user context inside shell (su, sudo)
• Not all processes are shell-spawned; daemons, kernel threads live independently

Core Unix Commands (sample subset)

• File/navigation
  • ls, cp, mv, rm, pwd, cd
• Viewing / searching
  • less, cat, grep, head, tail, wc
• Process management
  • ps, kill
• Text munging (ideal for .csv manipulation)
  • cut, paste
• Manuals: man <command> → essential for mastering options

Redirection & Piping

• Streams: stdin (input), stdout (output), stderr (errors) – all files under the hood
• Redirection
  • Input: prog < in.txt (feed file into stdin)
  • Output: prog > out.txt (stdout to file); >> appends
• Piping (|)
  • Connect stdout of left cmd to stdin of right cmd
  • Example ls | wc -l → count files by piping directory listing into line-counter
• Chaining many tiny commands often beats writing bespoke code but can be cryptic ➜ comment your one-liners!

C & Unix Tight Coupling

• Large portions of Unix re-written from assembly to C → language & OS “speak” natively
• C standard library exposes wrappers for syscalls (system(), execvp(), signals, pipes, low-level IO)
• Learning C provides insight into lower-level mechanisms hidden by modern languages
  • Clarifies what high-level languages/libraries are abstracting (and what can go wrong)
• Personal anecdote: author mostly used Java/Python/etc., but C knowledge proved valuable (e.g., FPGA code translation in 2022)

Ethical / Practical Implications

• Misconfigured permissions (chmod) can compromise security or break marking pipelines
• Understanding kernel boundaries prevents accidental system damage when running as root
• Powerful one-liners accelerate workflows but demand caution; opaque scripts may hinder maintainability

Study Checklist / Connections

• Practice ls -l to decode permission strings by eye
• Create sample directories, experiment with relative vs. absolute cd
• Write tiny bash scripts, test redirection & pipes (grep, cut, paste)
• Use ps, kill, &, and nohup to see parent/child relationships
• Revisit C basics beside this Unix material; map fork, exec, wait to shell behaviour observed above