📜Module 10 — Bash Scripting

Hello from a script
I am running as: zaeem

(printed twice — once per way of running it)

What to read out of it:

• Both invocations produced identical output, but by different mechanisms: ./hello.sh made the kernel read the shebang and launch bash; bash hello.sh launched bash directly and handed it the file. Knowing both matters — the second is how you run a script you can't (or don't want to) chmod.
• $(whoami) ran inside the script exactly as it does at the prompt (Module 5's command substitution) — a script is just your shell's grammar, saved to a file. Everything you know at the prompt works here.
• The cat > file <<'EOF' … EOF you've been pasting since Module 6 is a heredoc: it feeds the lines up to EOF into the file. The quotes around 'EOF' stop the shell expanding $(whoami) while writing the file — you want that expansion to happen when the script runs, not when it's created. Unquoted EOF would have baked in your current username. A quoting subtlety with real consequences.

Script name: ./args.sh
First argument: alpha
All arguments: alpha beta gamma
Number of arguments: 3

then, with no arguments:

Script name: ./args.sh
First argument: 
All arguments: 
Number of arguments: 0

What to read out of it:

• With arguments, $1/$@/$# reported exactly what you passed. With none, $1 and $@ came back empty — no error, no warning. That silent emptiness is the single most common source of script bugs, and $# (count zero) is how a well-written script detects it before doing damage.
• A script that acts on $1 without checking $# first will, run with no argument, operate on the empty string — deleting "", deploying "", connecting to "". Part B's first job is to make that impossible.

The shebang (#!/usr/bin/env bash or #!/bin/bash) is the script's first line; the kernel reads its #! marker when you execute the file by path and launches the named interpreter to run the script. #!/usr/bin/env bash locates bash via PATH (portable across systems where bash lives in different places); #!/bin/bash hard-codes the location (predictable, common on Linux). To bash itself the line is a comment.

The details that separate candidates: that it only takes effect when running ./script (not bash script, which names the interpreter directly); the env vs hard-path trade-off (portability vs predictability); and the failure mode — a #!/bin/sh shebang runs the script under dash on Debian/Ubuntu, breaking bash-only syntax (Module 1's dash lesson, now with teeth).

Pass them after the script name (./deploy.sh web-01 v2); access them inside as positional parameters: $1, $2, … for individual arguments, $@ for all of them, $# for the count, $0 for the script name. Always double-quote them ("$1", "$@") to survive spaces. $@ inside double quotes uniquely expands to each argument as its own word — the correct idiom for forwarding arguments to another command. (Turing's variant: cwd="$(pwd)" — command substitution into a variable, Module 5.)

The details that separate candidates: "$@" vs "$*" (the former keeps arguments separate, the latter joins them into one string — the B-part interview question); shift to consume arguments in a loop; and validating $# before use, because unsupplied parameters expand to empty strings silently.

/etc/hostname is a regular file
/etc is a directory
/nope does not exist

What to read out of it:

• Three inputs, three branches — the script decided rather than blindly acting. Every one of those -f/-d/-e tests is Module 3's stat metadata, exposed as a yes/no.
• The quoting of "$target" is not decoration: run ./check.sh with no argument and it still works (reports the empty string "does not exist") because the variable is quoted — unquoted, [[ -f $target ]] with an empty target becomes [[ -f ]], which tests whether the string "-f" is non-empty (always true), silently misrouting. The quotes are load-bearing.

checking web-01
checking web-02
checking db-01
found log: a.log
found log: b.log
line: first
line: second
line: third

What to read out of it:

• The glob loop found exactly the .log files and skipped c.txt — bash expanded *.log to real filenames before the loop ran (Module 5's globbing, in a loop). Note it did not run ls; the glob is the list.
• while IFS= read -r processed each line intact. This exact idiom — over a file, or over a command's output via a pipe — is how you iterate log lines, config entries, or a list of hosts in a script. Memorize its shape; the IFS= … -r looks like noise but each piece prevents a specific real bug.

It is now 14:32:07
4 is even
7 is odd

(the time is your machine's own)

What to read out of it:

• timestamp returned data — captured with $(...) into now. is_even returned status — tested with if. Two functions, two channels, cleanly separated. This is the pattern for every helper you'll write.
• is_even has no echo and no return — its status is simply that of its last command, the (( )) test, which is exactly the yes/no you want. That's idiomatic bash: a predicate function is just a test whose success is the answer.

[ is the POSIX test command (a program/builtin): works everywhere, but needs careful quoting and mishandles empty/unset variables. [[ ]] is bash's keyword test: safer with variables, supports &&/|| and pattern matching (== with globs), no word-splitting surprises — the default for bash scripts. (( )) is arithmetic evaluation: for numeric comparisons ((( n > 3 ))), where you use >/</== on numbers and don't need $ on variables inside.

The details that separate candidates: choosing [[ ]] for strings/files and (( )) for arithmetic as a habit; knowing [ needs spaces around every token because it's literally a command receiving arguments; and the portability note — a script targeting POSIX sh (a #!/bin/sh shebang) cannot use [[ ]] and must fall back to [ ], which is why [ ] still matters.

Define with name() { commands; }, call as name arg1 arg2 (arguments become the function's $1, $2, $@). Two return channels: status via the exit code (last command's, or return N where N is 0–255) — test it with if name; then; data via echo/printf captured with result="$(name)". Use local var inside to avoid polluting the caller's variables.

The details that separate candidates: the status-vs-data distinction stated crisply (and the classic bug of return-ing a large number, which wraps mod 256); local for hygiene; and that a predicate function needs neither echo nor return — its last test's status is the answer, the idiomatic bash predicate.

Both expand to all positional parameters; the difference appears when quoted. "$@" expands to each argument as a separate word — "$1" "$2" "$3" — preserving boundaries, so it's the correct way to forward arguments to another command. "$*" joins all arguments into a single word separated by the first character of IFS (a space by default) — useful when you genuinely want one string. Unquoted, $@ and $* behave identically (both word-split), which is why the quoted forms are what matter.

The details that separate candidates: "the difference only shows when quoted" — the whole point; a concrete use for each ("$@" to pass args through, "$*" to build a log message); and connecting it to the loop for arg in "$@" being the safe way to iterate arguments including those with spaces.