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
  • 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