Terminal Navigation, Shell Basics & Executables

Before writing automation scripts, you must master the target operating system’s filesystem, shell execution pipe, and permission maps.

Topic 1: Terminal & Linux Basics

The terminal is a text-based way to control your computer. Instead of clicking a folder icon, you type cd foldername. Instead of dragging a file to trash, you type rm filename. Everything a script does is just these same commands, saved into a file so you don’t have to type them one by one.

Command Flag Lookup Table:

When running shell commands, their behaviors are customized using options (flags):

Under the Hood: Directory structure & Paths

Linux maps filesystems as a single unified tree structure starting from the root directory /. Key directories to know:

• /bin & /usr/bin — Stores standard executable binaries (like ls, grep, bash).
• /etc — Stores system and application configuration files (e.g. /etc/nginx/nginx.conf).
• /var/log — Standard directory where the OS and running processes write their log streams.
• /tmp — Temporary folder. Contents are typically cleared automatically upon system reboots.

Path Resolving Mechanics:

• Absolute Paths: Start from the root directory / (e.g. /var/log/nginx/access.log). They resolve identically regardless of your current directory.
• Relative Paths: Start from your current position (e.g. ../reports/build.log). Use . for the current directory and .. for the parent.
• Inodes and Directory Links: In Unix, every directory contains two default links: . pointing to the directory itself, and .. pointing to its parent. These are hardlinks to the directory inodes on the filesystem storage device.

Try it yourself: Without looking anything up — pwd, then mkdir devops-practice, cd devops-practice, touch notes.txt, ls -la, mkdir logs.

Common mistake: Confusing absolute paths with relative paths. This causes “No such file or directory” errors because the terminal looks relative to your current location rather than the root directory. When confused, run pwd first.

Topic 2: The Shell Itself

”The shell” is the actual program reading what you type and translating it into instructions for Linux. bash is the most common one — think of it as the translator standing between you and the operating system’s kernel (the deep engine that actually talks to the hardware).

Kernel-space vs. User-space Interaction:

The Linux operating system is divided into two security spaces:

1. Kernel-space: Where the core OS code runs, having unrestricted access to the CPU, memory, and devices.
2. User-space: Where user applications (like the shell, web browsers, and text editors) run. Applications must make system calls (syscalls) to ask the kernel to perform operations (like reading files or writing to screens).

+-----------------------------------------------------+
|                     User Space                      |
|  +-------------------+      +--------------------+  |
|  |   User Terminal   | ---> |  Translating Shell |  |
|  +-------------------+      +--------------------+  |
+--------------------------------|--------------------+
                                 v System Calls
+--------------------------------|--------------------+
|                     Kernel Space                    |
|             +----------------------------+          |
|             |        Linux Kernel        |          |
|             +----------------------------+          |
+-----------------------------------------------------+

The Shell Translation Pipeline:

When you execute a command, the shell processes it through three main phases:

1. Lexical Analysis (Tokenization): Splits the raw text string into a list of logical tokens (words, parameters, redirects).
2. Parsing: Arranges the tokens into an Abstract Syntax Tree (AST) checking grammar and keywords (like if, for).
3. Execution: Resolves paths, performs substitutions, forks child processes, and runs commands.

Shell Comparison Matrix:

• sh (Bourne Shell) — The original Unix shell. Minimal, extremely fast, standard across all Unix platforms (POSIX compliant).
• bash (Bourne Again Shell) — Expanded standard with arrays, syntax highlights, and history logs. Default on most Linux systems.
• zsh (Z Shell) — Built with auto-completions and custom theme plugins. Default shell on modern macOS.

Try it yourself: Run echo $SHELL to see which shell you’re currently using. Then run bash --version to confirm bash is installed.

Topic 3: Writing Your First Script

A script is a plain text file (usually ending in .sh) containing a sequence of commands. The very first line is special — it’s called the shebang: #!/bin/bash. This tells Linux “use the bash program to run everything below this line,” even if the person running it is using a different shell.

The Execve System Call:

When you execute a script via ./script.sh, the operating system triggers the execve system call. The kernel inspects the first two bytes of the file. If they are #! (hex 0x23 0x21), it parses the remaining characters on that line as the interpreter binary path, loads that interpreter, and passes the script file path to it as an argument.

Standard vs. Portable Shebangs:

• Hardcoded shebang: #!/bin/bash — Points directly to /bin/bash. Fails if the bash binary is installed in a different location (like /usr/local/bin/bash on FreeBSD).
• Portable shebang: #!/usr/bin/env bash — Invokes the env utility to locate bash inside the system’s $PATH directories. Highly portable across Unix systems.

The anatomy of a basic script:

#!/bin/bash
# This is a comment — ignored by the shell, but helps humans understand the code
echo "Hello, DevOps!"

Try it yourself: Create hello.sh with the shebang, a comment, and an echo line greeting yourself by name. Make it executable and run it.

Common mistake: Forgetting the shebang, or putting a space before ! (# !/bin/bash is wrong — it must be #!/bin/bash exactly, no space). Without it, the script might still run, but it’ll use whatever shell your terminal defaults to instead of the one you intended — leading to confusing bugs down the line.

Topic 4: File Permissions

Every file in Linux has three permission types — read (view it), write (edit it), execute (run it) — and three groups of people they apply to: the owner, the group, and everyone else. Run ls -l and you’ll see something like -rwxr--r--: that’s owner=read/write/execute, group=read-only, everyone=read-only.

Mathematical Octal Permissions Mapping:

Linux represents permissions using a 3-bit binary map for each group (Owner, Group, Others), where:

• r (Read) = Binary 100 = Decimal 4
• w (Write) = Binary 010 = Decimal 2
• x (Execute) = Binary 001 = Decimal 1

Adding these values determines the permissions of a group:

• 7 = 4 + 2 + 1 = rwx (Full permissions)
• 6 = 4 + 2 + 0 = rw- (Read & Write)
• 5 = 4 + 0 + 1 = r-x (Read & Execute)
• 4 = 4 + 0 + 0 = r-- (Read Only)

Octal Mode: 755
Owner (7) : rwx (4 + 2 + 1)
Group (5) : r-x (4 + 0 + 1)
Others(5) : r-x (4 + 0 + 1)

Ownership Commands:

• chmod (Change Mode): Alters access permissions (e.g. chmod 755 script.sh).
• chown (Change Owner): Alters file user owner and group mapping:

  # Change owner to 'ubuntu' and group to 'www-data'
  sudo chown ubuntu:www-data config.env
  

Try it yourself: Create a script, try running it with ./script.sh before adding execute permission (watch it fail), then run chmod +x script.sh and try again.

Common mistake: Using chmod 777 (permission for absolute everyone to read/write/execute) out of frustration when a permission error appears, instead of understanding which permission was actually missing. This is a real security habit to unlearn early — in DevOps environments, overly permissive files are a common audit flag.