Shell Scripting: Concepts, Construction and Execution

10.1 Shell Scripting Fundamentals: Purpose, Definition and Program versus Script

10.1.1 What a Shell Script Is and Why We Group Commands

A shell script — a plain text file that stores a sequence of shell commands for the shell to read and execute in order — solves that repetition problem. A shell, the command interpreter that sits between you and the operating system kernel, is the program that reads what you type, parses it, locates the executable, runs it, and prints the result on your terminal.

The core idea is deceptively simple: execute a series of commands together, in one go, reproducibly. Instead of typing who then waiting, then ls, then date one by one at the prompt, you queue those lines in a file such as first.sh and ask the shell to run the file. The file becomes a saved workflow, a recipe card the shell follows line by line.

This matters because manual repetition is fragile. You might mistype a flag (ls -l versus ls -I), forget a step in a deployment checklist, or run commands in the wrong order and clobber a file before backing it up. A script locks the order, flags, and arguments in place, making the workflow auditable and repeatable.

who
ls
date

bash first.sh

Visual intuition: imagine a vertical flowchart with three boxes stacked — who at top, ls in middle, date at bottom — connected by downward arrows labeled "shell reads next line". The x-axis is time, the y-axis is command index. No branches, no loops yet. The shape is a straight pipeline. The takeaway is that control flows top-to-bottom with no jumps at this stage.

10.1.2 How a Shell Executes Commands from a File

When you type interactively, the shell loop is: read one line from the terminal → parse → execute → wait → prompt again. When you use a script, the loop is identical except the source of lines is the file, not the keyboard. The phrase used in class to cement this is: the shell reads and executes commands contained in a file.

Unpack that phrasing. The script does not "run" by magic. A shell process — identified by its PID, visible via echo \$\$ — opens the file as input, reads the first line into memory, forks and execs the command if it is external, waits for the exit status, then reads the second line. The file provides the characters; the shell provides the engine. This is why the same file can be run by different shells with different results: bash first.sh feeds the file to bash, sh first.sh feeds it to sh. The kernel's role is minimal at this stage — it just starts the interpreter you named.

A useful mental trace: bash first.sh → kernel starts bash → bash opens first.sh for reading → while not EOF: read line, expand variables, handle meta characters, execute, store \$?. Interactive bash does the same but with stdin tied to your keyboard.

10.1.3 Script versus Program: Interpretation, Constructs and Modularization

Why call this a script and not a program? In everyday talk you call Java or C code a program. The distinction here is not about importance but about how the code is handled and how heavyweight the language feels.

A program in a language like Java or C is typically seen as a full-featured construct with rich data structures, extensive libraries, and a distinct build step that translates source into machine code or bytecode before any execution happens. A script in the shell context is a list of commands that is interpreted — the interpreter reads the file and acts on it directly, line by line, without a separate compilation step. Bourne's classic line captures it: the shell is a programming language in which each statement runs a command.

Comparison table — script versus program as framed in this lecture:

When to pick which: if the task is chaining system utilities, checking file states, or looping over file lists, a shell script wins on speed of authoring. If the task needs complex data structures or high performance, a compiled program wins. The professor stresses that many real jobs are glue — and for glue, interpretation is a feature, not a limitation.

Real-world and domain connection: Shell scripts are the workhorses for repeatable operational tasks on Unix and Linux — nightly tar backups, grep ERROR app.log | wc -l health checks, rsync deployments, and CI runners that invoke bash build.sh — because they remove manual repetition where a GUI would require clicks. In systems programming broadly, they sit alongside C and assembly as the glue layer: C builds the tools, shell scripts orchestrate the tools into pipelines.

10.2 Creating a Shell Script File

10.2.1 Grouping Commands with an Editor

Creating a script is literally grouping a list of commands you would otherwise type, one per line, in a text file. You open a text editor, enter commands, save, and run. The editor used in the live demo is vi — the visual editor present on virtually every Unix system — and the steps narrated are: vi one_st.sh to open (or create) the file, i to enter insert mode, type commands, Esc then :wq to write and quit. Those vi moves are worth memorizing because on a minimal server vi may be the only editor available.

The filename in the demo evolves from first.sh to one_st.sh simply because first.sh already existed — the second name was "one more start" file. The suffix .sh is a human convention signaling "shell script"; the kernel and shell do not require it. myscript, one_st, or snapshot would run identically if invoked correctly. The convention helps humans and tools like ls *.sh to locate scripts quickly.

ls
ls -l
date
who
hostname

10.2.2 Demonstration with ls, date, who and hostname

ls
ls -l
date
who
hostname

bash one_st.sh

first.sh  one_st.sh
total 12
-rw-rw-r-- 1 centos centos  45 Feb 21 15:00 first.sh
-rw-rw-r-- 1 centos centos  52 Feb 21 15:10 one_st.sh
Mon Feb 21 15:38:19 IST 2026
centos pts/0  2026-02-21 15:21 (10.0.2.15)
server01.example.com

A common early question is whether this simple grouping is the "right" way. The answer in class is: yes, it will run, but it is not yet robust or portable. Without a shebang, direct ./one_st.sh may invoke the wrong shell; without chmod +x, it is not executable; without quoting and variables, it cannot adapt to arguments. The refinements that follow — shebang, permissions, wildcards, meta characters, variables, and conditionals — turn a raw command list into a reliable script that survives being moved to another machine or being run by cron.

Visual: picture a stack of dominoes labeled ls → ls -l → date → who → hostname. Pushing the first domino (bash one_st.sh) tips them in order, each fall is a command's output. No domino branches — that visual will change once if is introduced.

Real-world: This grouping is how operators build daily snapshot scripts — uptime; df -h; free -m; who saved as morning_check.sh — so the morning health check is one command, not five, and can be mailed or logged automatically.

10.3 The Shebang Line and Two Execution Methods

10.3.1 Purpose and Syntax of the Shebang

The shebang — the first line of a well-formed script, written as #!/bin/bash — answers that question. The characters are hash # followed by bang ! (so hash-bang), then the absolute path to an interpreter. In #!/bin/bash, /bin/bash points to the Bash interpreter binary.

Common variants you will see: #!/bin/sh (POSIX Bourne shell, often a symlink to bash or dash), #!/usr/bin/env bash (search PATH for bash, more portable), #!/bin/python3 for Python scripts. For this lecture the standard is #!/bin/bash.

10.3.2 Explicit Invocation versus Executable Permission

There are two distinct ways to run the same file, and the role of the shebang differs between them.

bash first.sh
sh first.sh

chmod +x first.sh
./first.sh

A subtle but exam-tested point: explicit invocation works even if the file is not executable and even if the shebang line is missing or wrong. Direct execution fails without x permission (Permission denied) and falls back to a default shell if the shebang is missing.

10.3.3 Making a Script Executable with chmod and Direct Execution

The command chmod +x first.sh modifies the file mode. chmod is change mode, +x adds execute permission. Without a qualifier, +x applies to user, group, and others — after the command you see rwx style flags for all three categories. With ls -l you move from -rw-rw-r-- to -rwxrwxr-x.

The focused question about user-only permission draws out the precise syntax: to add execute permission only for the user, write chmod u+x first.sh, where u restricts the change to the user class. The confirmation in class is: that is very right, u+x is the form for user-only. Other forms for completeness: g+x for group only, o+x for others only, a+x equals bare +x (all), chmod 755 file sets rwxr-xr-x numerically.

Once executable, the file runs by naming it: ./first.sh when in the current directory (the ./ avoids PATH search), or just first.sh if its directory is already on \$PATH or copied to ~/bin. You still see the same combined output — who, ls, date, hostname — but now dispatch is via the shebang rather than your explicit bash.

#!/bin/bash
who
ls
date
hostname

10.3.4 When the Shebang Matters and When It Does Not

If you always run scripts as bash script.sh, the shebang carries no operational weight — it is a comment that the invoked bash skips. If you run scripts as ./script.sh, via cron, via find -exec, or as a login script, the shebang is essential because no human is typing the interpreter name.

The discussion revisits this by removing the shebang line and running with bash — it still works, because the interpreter is explicit. Then the shebang is restored to #!/bin/bash or changed to #!/bin/sh, the file is made executable again, and direct execution is shown to follow whichever interpreter the shebang names. Switching to #!/bin/sh on a Bash-specific script that uses [[ or (( )) will then fail under dash-based sh — a classic portability bug.

Visual: draw two flowcharts side by side. Left: bash first.sh → arrow labeled "you chose bash" bypasses shebang → bash reads file. Right: ./first.sh → kernel checks first bytes → branch: #! present → launch that interpreter; absent → launch \$SHELL (/bin/bash here). The takeaway is the decision diamond is the presence of x permission plus #!.

Real-world: Teams standardize on #!/bin/bash (or #!/usr/bin/env bash) and rely on direct execution so that cron jobs, systemd units, and CI pipelines do not need to remember which interpreter to name — the file itself declares its runtime.

10.4 Shell Variants and the Default Interpreter

10.4.1 Families of Shells: sh, bash, csh, ksh and zsh

Bash is not the only shell. The session enumerates several distinct programs, each providing a prompt and a scripting language:

• sh — the original Bourne shell (Stephen Bourne, 1979), the POSIX baseline. On many Linux systems /bin/sh is a symlink to bash or dash, but the language is the minimal portable subset.
• bash — Bourne Again Shell, GNU's superset of sh with arrays, [[ ]], (( )), and brace expansion. This is the standard for this lecture and for most Linux distributions.
• csh — C shell (Bill Joy), with C-like syntax (set, foreach, if ( )). Loved interactively, awkward for scripting.
• ksh — Korn shell, a Bourne-compatible shell with C-shell-like interactive features; common on older commercial Unix.
• zsh — Z shell, a modern ksh-compatible shell with advanced completion and floating-point arithmetic.

In the demo environment, bash, sh, and csh were present, while ksh and zsh were noted as not installed in that particular CentOS setup — ksh --version or zsh --version would report "command not found" until installed. The point is that each name denotes a separate binary at a distinct path (/bin/bash, /bin/sh, /bin/csh), not just a mode flag.

10.4.2 Construct Compatibility Across Shells

Because each shell is a different program, the way they handle programming constructs varies — sometimes subtly, sometimes incompatibly.

Examples that bite in practice:

• bash supports [[ \$str == pattern ]], (( i++ )), function foo(), and arrays arr=(a b c). sh (as dash) does not — it needs [ "\$str" = pattern ], i=\$(expr \$i + 1), and no arrays.
• csh uses set var = value (spaces required), if ( \$x == 1 ) then, and foreach. A bash script with var=value fails under csh.
• ksh and zsh add floating-point \$(( )) and associative arrays that bash only partially matches.

You can test this yourself by running the same file with different interpreters: bash first.sh versus sh first.sh versus csh first.sh. If the file uses only ls, date, and who, all three produce the same output. If it uses if [[ \$x -eq 5 ]] or (( )), sh and csh will error. For day-to-day work the advice in class is that bash is the standard for executing shell scripts precisely to keep construct handling predictable. Knowledge of the variation matters when you move a script from Linux (bash) to a BSD system where /bin/sh is ash or to a machine where ksh is default.

10.4.3 The Default Shell and the SHELL Environment Variable

An environment variable — a named value that the shell maintains for the session, for the environment in which commands run — controls defaults. Several appear in the demo, always by convention in capitals to distinguish them from your own lowercase variables.

\$SHELL holds the default interpreter pathname. Running echo \$SHELL prints /bin/bash in this setup. When a script lacks a shebang and is executed directly (after chmod +x), the system consults this default — the conceptual equation is simple: if shebang present, use shebang path; if absent, use the value of \$SHELL (or /bin/sh on kernel fallback, lecture states \$SHELL).

Other environment variables shown as system variables include:

You inspect them with echo \$PATH, echo \$SHELL, etc., where the dollar retrieves the stored value. Try echo \$HOME versus echo HOME — without \$ you print the literal word.

Visual: imagine a table of Post-it notes on the wall of your session. Each note is labeled in capitals (SHELL, PATH) with a value. Child processes inherit copies of those notes (exported variables), but scribbling on a child's copy does not change the parent's wall — that is why export matters, previewed for later lectures.

Real-world: Portability bugs often trace back to an incorrect shebang or an assumption about which shell is default on a Docker image or a client's server. Explicitly writing #!/bin/bash and testing with shellcheck -s bash or with both bash and sh catches those mismatches early.

10.5 Wildcards and Pattern Matching

10.5.1 The Star, Question Mark and Bracket Wildcards

The shell interprets certain characters as patterns before it even runs the command — these are wildcards (also called globs). Expansion happens in the shell, not in ls or rm; the command sees the already-expanded list.

10.5.2 Negation, Ranges and Combined Patterns

Visual: imagine a row of four slots for a filename pattern [EI][xf]*.*. Label slots 1,2,3,4. Slot 1 shows two cards E/I; slot 2 shows x/f; slot 3 shows a stretchy * accordion; slot 4 shows dot plus *. Any filename must place one card per fixed slot, the * stretches to fit the remainder. The takeaway is that pattern matching is positional replacement.

10.5.3 Practice Patterns and Expected Listings

The session points to worksheets to practice: try *, *.sh, ?.sh, ??*, *.*, ??_*.sh, and bracket forms, and compare the listings against ls without a pattern. The key intuition repeated is that ? is strict about occupying one slot while * is greedy about occupying any number of slots, and brackets narrow the choice at a single slot. That contrast — * is any length including zero, ? is exactly one, [ ] is exactly one from a set — is the one sentence to carry into practice.

Try this self-test with the file list above: ls ???.sh matches three-character names plus .sh → E1.sh would not match (only 2 before dot), Ex1.sh would? Ex1 is three before dot, so yes. ls ??_*.sh matches two chars, underscore, anything, .sh — designed for names like if_x.

Real-world: Wildcards power quick file selection in administration — ls *.log, rm temp_??.txt, cp data_[0-9]* /backup, cat access_[0-9][0-9].log | grep ERROR — and small mistakes in the pattern can select the wrong files, so precise understanding of * versus ? versus [ ] prevents accidental deletion or missed backups.

10.6 Meta Characters and Command Composition

10.6.1 Redirection, Append, Input Redirection and Pipes

A meta character — a character the shell treats specially, not as a literal letter — controls where input comes from and where output goes. The I/O meta characters are the glue for data plumbing.

a.txt
b.sh
ls.out

10.6.2 Command Terminators and Sequential Execution

A point of precision: ; is unconditional, while && and || (next) are conditional.

10.6.3 Logical Connectors and Short-Circuit Behavior

Visual: imagine traffic lights. ; is a roundabout — you always go to the next road. && is a green-only gate — you proceed only if the light was green (status zero); || is a red-only detour — you divert only if the light was red (non-zero).

10.6.4 Quoting, Escaping and Comments

Real-world: Redirection and pipes are the glue for log handling and data pipelines — grep ERROR app.log > errors.txt, cat data.csv | sort | uniq > clean.txt, make 2> build.err | tee build.log — and correct escaping of * and ? prevents the shell from expanding a multiplication sign into a file list.

10.7 Variables, Command-Line Arguments and Quoting Rules

10.7.1 Positional Parameters from \$0 to \$9

A command-line argument — a word you add after a command when you run it, so the command can vary its behavior — is that answer. For shell scripts, those arguments are exposed inside the script as positional parameters, the exclusive special variables \$0 through \$9.

./script.sh alpha beta gamma
# \$0 = ./script.sh
# \$1 = alpha
# \$2 = beta
# \$3 = gamma
# \$# later = 3 (count, covered in 10.8)

10.7.2 Creating Variables and Accessing Values with \$ and \${}

You can create variables inside a script at will — no declaration, no int keyword, no import. The creation rule is simple and strict: $$\text{variable=value}$$ with no spaces around =. Examples shown are number=10 (numeric string), vec=bus (word), and str=V (single character). Assigning a null value as vec= is allowed and means empty — the variable exists but holds the null string.

To use the value stored in a variable, you prefix the name with \$. The form \$var expands to the value of var, while \${var} does the same with braces that delimit the name explicitly. Braces disambiguate when the variable name abuts other characters: \${var}x is the value of var plus x, while \$varx would look up a different variable varx.

read name        # name is the container (no \$)
echo Hello \$name # \$name is the content of that container

#!/bin/bash
number=10
vec=bus
str=V
echo \$number \$vec \$str
echo \${number}ish
vec=
echo empty is [\$vec]
value1=10
value2=\$value1
echo value2 is \$value2

Visual: draw two boxes — a closed box labeled name (the variable name) and an open box showing its contents Tixna labeled \$name. read points to the closed box (fill it), echo points to the open box (read it).

10.7.3 Assignment Rules and Spacing Requirements

Two spacing rules are repeated as nitty-gritty that varies by shell and by command and therefore must be remembered for bash:

The overall pattern for this section is: dollar for access, no spaces for assignment, spaces for arithmetic operators — three mnemonics that prevent 80% of beginner syntax errors.

Real-world: Argument-driven tooling depends on this mapping — backup.sh \$1 where \$1 is a filename, deploy.sh \$1 \$2 where \$1 is environment and \$2 is version — with if [ \$# -ne 2 ] guarding usage, as you will see in 10.8.

10.8 Special Shell Variables Exclusive to Scripts

10.8.1 PID of the Current Shell with \$\$, Process Listing

Special variables are names the shell reserves for script-level bookkeeping — exclusive to scripts and the shell itself, not for you to define.

The first one examined is \$\$, which expands to the process identifier (PID) of the current shell — the numeric ID the operating system assigns to the running shell process. Every running shell, every command, and every script has a distinct PID visible via ps.

10.8.2 Filename, Parameters, All-Parameters and Count

#!/bin/bash
echo PID is \$\$
echo File is \$0
echo First is \$1
echo Second is \$2
echo All is \$*
echo Also is \$@
echo Count is \$#
echo Status is \$?

Visual: imagine a dashboard with gauges. Gauge \$# shows a single number (count). Gauge \$*/\$@ shows a long tape with all words. Small dials \$1, \$2 show individual words. Dial \$\$ shows your badge number, and warning light \$? glows green for 0 or red for non-zero after each command.

10.8.3 Exit Status and Worked Demonstration

./shell_variables.sh

PID is 6167
File is ./shell_variables.sh
First is 
Second is 
All is 
Also is 
Count is 0
Status is 0

./shell_variables.sh 1 2 hello 5

PID is 6172
File is ./shell_variables.sh
First is 1
Second is 2
All is 1 2 hello 5
Also is 1 2 hello 5
Count is 4
Status is 0

Real-world: \$# is the guard for argument validation (if [ \$# -ne 2 ]; then echo "usage: \$0 file1 file2"; exit 1; fi), \$? drives error handling after a critical cp or grep, and \$\$ seeds temporary file names (/tmp/build.\$\$) or lock files so parallel CI jobs do not clash.

10.9 Interactive Scripts and Real-World Use

10.9.1 Making Scripts Interactive with echo, printf and read

A script can ask the user for input at run time and then act on that input — this is an interactive script. Up to now arguments arrived via \$1 on the command line; interaction brings data via the keyboard during execution.

#!/bin/bash
# this is a comment line
echo What is your name\?
read name
echo Hello \$name

10.9.2 Escaping the Question Mark Prompt

Visual: picture the shell's preprocessing pipeline: raw line echo What is your name? → expansion phase where ? tries to match files → echo sees expanded words. Inserting \ short-circuits expansion: echo What is your name\? → escape phase strips \ and protects ? → echo sees literal ?.

10.9.3 Worked Interactive Example with Name Input

#!/bin/bash
# this is a comment line
echo What is your name\?
read name
echo Hello \$name
echo Happy programming

What is your name?

Hello Tixna
Happy programming

What is your name?
Hello Rajesh
Happy programming

10.9.4 Industry Application: Menu-Driven Test Harness for Banking

Beyond toy prompts, the same interactive pattern scales to operational work at industrial scale.

A recent industry project described involves core banking migration from a manual, paper-driven process to a core banking system (CBS). Within the accounts domain alone there were 23 test scripts, each checking a different functionality — account creation, balance enquiry, interest posting, statement generation, etc. Running them manually required remembering each script's name and repeatedly typing bash /path/to/test_account_create.sh, bash /path/to/test_interest.sh, with long paths and risk of typing the wrong test before a release.

The solution was a single interactive shell script — a harness or menu-driven driver — that ran in a loop:

#!/bin/bash
while true
do
  echo "==== Accounts Test Menu ===="
  echo "1) Create account"
  echo "2) Balance enquiry"
  echo "..."
  echo "23) Statement generation"
  echo "0) Exit"
  echo "Enter choice: "
  read choice
  case \$choice in
    1) bash tests/test_create.sh ;;
    2) bash tests/test_balance.sh ;;
    # ...
    0) exit 0 ;;
    *) echo "Invalid choice" ;;
  esac
done

The harness displayed a menu mapping numbers to functionalities, read a number from the operator, case dispatched the corresponding functional script, showed results, and looped back for the next choice. Instead of typing a long command for each test, the operator typed 7 and the harness dispatched the right test and returned. Because the choice was read with read, the harness remained interactive; because dispatch used positional mapping via case or \$choice, adding a new test meant adding a new menu entry — no harness rewrite.

The narration stresses how this made life easy after a couple of days of struggle with manual typing and remembering paths — a few hours to write the harness saved hours every test cycle, and the same operator could run the full regression without being a shell expert.

Real-world: Similar menu-driven harnesses appear wherever many related jobs coexist — regression suites, deployment steps (1) deploy to staging 2) deploy to prod), backup options, or device flashing where a number chosen at run time selects among scripts — anywhere a keyboard choice should select a workflow without retyping paths.

10.10 Arithmetic Evaluation with expr and Modern Alternatives

10.10.1 Basic expr Usage and Operator Spacing

Shell arithmetic for integers is historically done with the expr command — the external expression evaluator from Bourne's original toolkit. On the command line you can type:

expr 3 + 5

and see 8 printed, because $3+5=8$. The same holds for subtraction, division, and remainder. The set of operators shown in class and in T3 Table 11-1 and R2 Table 8.12 includes + add, - subtract, * multiply, / divide, % remainder, plus string and comparison operators including pattern match and substring.

10.10.2 Escaping the Star and Handling Modulus

Two operators need special attention because they collide with shell wildcards and job control.

10.10.3 Using expr Inside Scripts with Backticks

Inside a script you typically want to capture the numeric result into a variable for later echo or if, not just print it to the terminal. The legacy way shown uses command substitution with backticks — the character that sits with tilde ~ on the US keyboard, not a straight single quote '.

sum=`expr \$x + \$y`

The script variables involved — x, y, sum, diff, mul, div, rem — are all user-named; when their values are later printed the form is echo \$sum etc., with the dollar to retrieve the value, per 10.7 rules.

10.10.4 Worked Arithmetic Script with Two Numbers

echo Enter first number
read x
echo Enter second number
read y
sum=`expr \$x + \$y`
diff=`expr \$x - \$y`
mul=`expr \$x \* \$y`
div=`expr \$x / \$y`
rem=`expr \$x % \$y`
echo Sum is \$sum
echo Difference is \$diff
echo Multiplication is \$mul
echo Division is \$div
echo Modulus is \$rem

10.10.5 Increment Variations and the \$(( )) Form

Incrementing a value — adding one — is shown in two styles that are equivalent in bash but belong to different eras.

x=10
val=`expr \$x + 1`

val=\$(( x + 1 ))

11
11

Visual: contrast two pipelines. Legacy: x → \$x → expr (fork external) → capture → val with a process fork dot. Modern: x → \$(( )) (shell internal, no fork) → val as a direct arrow — faster and not needing IFS tricks.

10.10.6 String Length and Complex Expressions

#!/bin/bash
echo Enter the string
read str
a=`expr length "\$str"`
echo \$a

a=10
b=10
c=10
d=10
res=`expr \$a \* \( \$b + \$c \) / \$d`

Real-world: expr is legacy but still appears in old scripts and exam papers; new code prefers \$(( )) for readability and performance, yet both respect integer arithmetic, so divide-by-zero and floating-point expectations must be handled separately — bc or awk for decimals, (( )) for in-shell integer loops.

10.11 User-Defined and System Variables

10.11.1 System Variables in Capitals: PATH, SHELL, HOME and Others

A system variable (often called an environment variable or shell variable) is a name the shell and the system maintain for the session, not a name you invent inside your own script. By convention its name is all capitals — that visual cue distinguishes institutional state from your temporary script state.

10.11.2 User-Defined Variables and Naming Rules

A user-defined variable is a name you invent inside your own script to hold a value you need — name, x, y, vec, str, sum, count, etc. No declare needed in simple cases; first assignment creates it. The value is always a string; numeric interpretation happens only when you apply arithmetic.

number=10      # legal, lowercase start
_Number=5      # legal, underscore start
var2=hello     # legal, digit after first char
2var=hello     # illegal — starts with digit → bash: 2var=hello: command not found
my var=hello   # illegal — space splits → bash: my: command not found
my-var=hello   # illegal — dash parsed as minus
vec=bus        # legal, as in lecture
vec =bus       # illegal — space before =
vec= bus       # illegal — space after =
echo \$vec      # prints bus
echo \${vec}ish # prints busish

10.11.3 Null Variables and Advice on Avoiding Confusing Names

A variable may be set to empty (null) as vec= with nothing after = — this creates vec with an empty value (zero-length string), which is allowed and sometimes used to clear a value before a loop or to reset a flag. if [ -z "\$vec" ] then tests for that emptiness.

Because ? and * are wildcards, and #, \$, ! have special meanings (length, PID, status, history), it is advised not to use those characters in variable names — they are likely to be misinterpreted as patterns or expansions rather than name characters. Keeping names to letters, digits, and underscores ([a-zA-Z_][a-zA-Z0-9_]*) keeps parsing predictable and avoids needing escapes.

The conceptual contrast that closes the section is simple and exam-ready: capitals for the system (PATH, HOME, SHELL), your own choice in lower case for user variables (number, vec), and strict spacing discipline for assignment (= with no spaces) versus arithmetic spaces.

Real-world: In deployment scripts, echo \$HOME finds the user's home for config writes, \$PWD logs where the job ran, and if [ -z "\$1" ] guards missing arguments using the null-variable pattern — all built on the capital-versus-lowercase contract.

10.12 Conditional Logic: if, test, String, Logical and File Tests

10.12.1 Exit Status Convention: Zero is True

In shell decision making, truth is encoded as an exit status number returned by every command, not as a boolean literal like true/false. The rule is the opposite of C:

Visual: imagine a number line with 0 highlighted green in the center labeled "true / go", and all other integers red on both sides labeled "false / stop". The takeaway is that only one value is green.

10.12.2 Syntax of if-then-else-fi

The if statement is the decision construct that branches on that exit status. Its skeleton is:

if condition
then
    commands
fi

if, then, and fi are keywords and must be present. fi is if spelled backwards and closes the block — a Bourne heritage trick to avoid needing braces. With an else branch:

if condition
then
    commands_when_true
else
    commands_when_false
fi

The condition slot is itself a command whose exit status if inspects. Most often that command is test or its bracket shorthand [ ... ], both covered next. You can also put any command there: if grep -q pattern file branches on whether grep found the pattern.

The keywords and the closing fi are the scaffolding; the condition slot determines which branch runs. Newlines before then and else matter — then and else are recognized only after a newline or a semicolon. So if [ \$x -eq 0 ]; then echo yes; fi is valid with semicolons, but if [ \$x -eq 0 ] then without a separator is a syntax error.

10.12.3 Worked Example: Odd or Even

x=13
res=\$(( x % 2 ))
if [ \$res -eq 0 ]
then
    echo Even
else
    echo Odd
fi

echo Enter number
read x
res=\$(( x % 2 ))
if [ \$res -eq 0 ]; then echo Even; else echo Odd; fi

10.12.4 Numeric Comparisons with test and Bracket Form

For numeric comparison, the operators are dash-letter forms, not C symbols:

if test 5 -eq 6

if [ 5 -eq 6 ]

10.12.5 String Comparisons and Empty Checks

For string comparison, simpler symbols and dedicated flags are used:

str=V
if [ -z "\$str" ]; then echo empty; else echo not_empty; fi  # not_empty
if [ -n "\$str" ]; then echo not_empty; else echo empty; fi  # not_empty
# Equality
str1=V
if [ "\$str1" = "\$str" ]; then echo Strings are equal; else echo not equal; fi  # Strings are equal
if [ "\$str1" != "\$str" ]; then echo not equal; else echo equal; fi  # equal
# Null guard
empty=""
if [ -z "\$empty" ]; then echo zero_length; fi  # zero_length

10.12.6 Logical Operators: Not, And, Or

x=5
if [ \$x -gt 3 -a \$x -lt 10 ]; then echo "3 < x < 10"; fi  # prints, both true
if [ \$x -eq 5 -o \$x -eq 7 ]; then echo "x is 5 or 7"; fi  # prints
if [ ! \$x -eq 0 ]; then echo "x not zero"; fi  # prints, x=5

10.12.7 File Property Tests and Worked Directory/Executable Checks

The shell can test properties of files via unary flags — a powerful alternative to ls that lets a script decide before it acts. Each flag is a single dash plus a letter, where case matters.

filename=\$1
if [ -d "\$filename" ]
then
    echo directory
fi

if [ -x "\$filename" ]
then
    echo executable
fi

Real-world: File tests guard every production script before touching data — if [ ! -f "\$1" ]; then echo "file not found: \$1" >&2; exit 1; fi or if [ -x "\$prog" ]; then "\$prog"; fi — and logical connectors let you combine guards: [ -f "\$1" -a -r "\$1" ] checks it is a regular file and readable before you try to cat it, while mkdir tmp || exit bails if creation fails.

Exam Guidance Summary

• Conduct — zero tolerance for copying: A serious warning was given that direct copying in the mid-session exams was detected, including wrong answers copied ditto with identical quotes and formatting. If copying recurs in the comprehensive exam, the stated consequence is a direct zero — even for a right answer — and a possible report to the WLP division. The message is that learning, not reproduction, is what is assessed; the risk of an identical wrong answer is high because it is proof of copying.

• Class context: 24 to 27 students are enrolled, but attendance in live sessions is lower; the work and practice are expected from those who attend regularly, and the detailed examples are the exam source.

• What the exam will lean on — shell scripting as a very important topic: Expect questions that check precise understanding of:

• The purpose of a script (grouping commands for the shell to read and execute sequentially, not the vague "system administration" label)
• The shebang line #!/bin/bash — when it is required (direct ./script.sh) versus ignored (explicit bash script.sh), and the fallback echo \$SHELL yielding /bin/bash when shebang is absent
• Executable permission with chmod +x (user, group, others) versus chmod u+x (user only) and the ls -l rwx view
• Wildcard patterns: * (any number including zero), ? (exactly one), [ ] (one of set), [! ] (negation), ranges [A-Z]/[0-9]/[a-z], and combined positional patterns like [EI][xf]*
• Meta characters and their distinct roles: > (overwrite), >> (append), < (input), | (pipe), ; (always next), && (next only if success), || (next only if failure), \ (escape), ' '/" " (quoting), # (comment, except #!)
• Positional parameters \$0 through \$9 plus \$*, \$@, \$# (count), \$\$ (PID), \$? (exit status where 0 is true)
• Interactive read and the container versus value distinction: read name versus echo \$name, and escaping \? for a literal question mark
• Spacing rules: no spaces around = for assignment (number=10) versus spaces required around expr operators (expr 5 + 3)
• Escaping \* and \( and \) for expr multiplication and grouping, and the difference between backticks ` ` and single quotes '`
• String length with expr length "\$str" (e.g., System length 6, and why System Programming without quotes errors)
• Complex expr with BODMAS: a * (b + c) / d with a=b=c=d=10 yielding 20
• The full if-then-else-fi structure including numeric tests -eq/-ne/-lt/-le/-gt/-ge, string tests =/!=/-n/-z, logical !/-a/-o, and file flags -d/-f/-r/-w/-x/-s/-e (plus -T/-B/-L with case sensitivity)
• The bracket spacing mandate: [ \$res -eq 0 ] with a space after [, before ], and around the operator — [ \$res -eq 0] or [\$res -eq 0 ] fails
• The contrast between test and [ ] (brackets are shorthand for test, hence the spacing), and that exit status 0 is true, non-zero is false, opposite to C

• Practice advice: A worksheet on wildcards (*, ?, bracket lists, negation, ranges) was assigned — try each pattern against a sample directory and compare listings. All examples shown in class are candidates for replication questions where you must write the script, show the command line, and state the output: shell_variables.sh empty versus 1 2 hello 5, interactive.sh with Tixna versus Rajesh, expr.sh with 10 and 3 yielding 13, 7, 30, 3, 1, expr_complex.sh yielding 20, if_odd.sh with 13→Odd then 12→Even, string equality with str=V, and if_dir.sh with ., .., ..., /home, and first.sh.

• Preparation for next session: The next meeting will continue shell scripting with the remaining constructs not yet covered (loops, functions, and more). An assignment and Quiz 2 will be announced before the following week with dates for execution. Studying the current set thoroughly — especially the spacing and quoting traps — before that continuation will keep the sequence intact and prevent compounding gaps.

Key Industry Applications

• Repeatable system administration and machine snapshots: Grouping who, ls -l, date, hostname, uptime, df -h, free -m and similar probes into one script such as morning_check.sh lets operators snapshot a machine state on demand or via a scheduler (cron or systemd timer). Instead of retyping five commands each morning and risking a forgotten flag, they run bash morning_check.sh > snapshot.\$(date +%Y%m%d).log and archive the result. This is the direct production use of the grouping idea from 10.1–10.2.

• Menu-driven test harness for large migration (banking core-system example): The industry project described had 23 test scripts in the accounts domain alone. Rather than remembering 23 paths and typing bash /long/path/test_create.sh each time, a single interactive loop displayed a numbered menu, read the operator's numeric choice, dispatched the matching test script via case, showed output, and looped back. This pattern generalizes to any regression suite, deployment matrix, or device-flashing workflow — anywhere a number or keyword chosen at run time selects among many scripts without retyping paths. Adding test 24 is one new menu line.

• Log and data pipelines using redirection and pipes: ls > file for fresh captures, ls >> file for accumulation across runs, 2> errors.log for error capture, and cat access.log | grep ERROR | sort | uniq -c | sort -n > summary.txt style pipelines that connect the output of one program to the input of the next. In production, this is grep ERROR app.log > errors.txt for triage, cat data.csv | sort | uniq > clean.txt for deduplication, and make 2> build.err | tee build.log for dual logging — all built on >, >>, | from 10.6.

• Argument-driven tooling using positional parameters: Scripts that take a filename or a threshold as \$1 and validate with \$# — the classic guard if [ \$# -ne 2 ]; then echo "usage: \$0 input output"; exit 1; fi — then branch and track success with \$?. Examples: backup.sh \$1 for the file to back up, deploy.sh \$1 \$2 for environment and version, process.sh data.csv 100 where \$2 is a threshold, all leveraging \$0..\$9, \$*/\$@, and \$# from 10.7–10.8.

• File-state guarding in unattended automation: Using [ -d path ] to check a directory exists before cd, [ -f file ] to confirm a regular file before parsing, [ -x prog ] to verify executability before running, [ -r file ] and [ -s file ] to check readability and non-emptiness, [ -e file ] for existence regardless of type, and combinations with -a/-o such as [ -f "\$1" -a -r "\$1" ] to decide whether to create, process, or skip a file in nightly jobs that run without human supervision — the direct use of the file tests from 10.12.

• Remote connection and orchestration scripts: Mentioned as a context where learners already use a shell script to ssh into a remote machine, scp a file, or rsync a directory. The same primitives extend outward: a local script can ssh user@host "bash -s" < local_script.sh to run a script remotely, or loop over a list of hosts and scp a config — illustrating that shell scripting reaches from local file handling to networked operation without leaving the language introduced in this lecture.