Computing Foundations › Systems Foundations: Storage, Observability, and Tooling › Day 36
Hands-on lab — Day 36: Choosing and Configuring a Code Editor
- ← Back to the Day 36 lesson
- Open the hands-on files on GitHub — clone or download them from the public labs repository
- Local path in your clone:
labs/sections/computing-foundations/day-036-choosing-and-configuring-a-code-editor/
Commands
Setup
cd labs/sections/computing-foundations/day-036-choosing-and-configuring-a-code-editor Run
bash examples/editorconfig_demo.sh
bash starter/editorconfig_demo.sh Test
bash tests/run_tests.sh File tree
examples/editorconfig_demo.sh expected-output/FIELDS.md expected-output/sample-run.txt metadata.yml README.md requirements/README.md security.md starter/editor-worksheet.md starter/editorconfig_demo.sh tests/run_tests.sh troubleshooting.md
Lab README
Day 036 lab — Configure Your Editor with EditorConfig
Lesson
- Lesson title: Choosing and Configuring a Code Editor
- Day number: 36 of 365
- Lesson article: https://ai-roadmap-365.github.io/day-036-choosing-and-configuring-a-code-editor
- Lab files: everything you need is in this directory — follow “How to run” below.
- Browse the course locally: from the repository root, this lab also appears in the course website at
/labs/day-036-choosing-and-configuring-a-code-editorwhen the site is running.
Purpose
Day 36's lesson explains how to choose and configure a code editor. This lab
makes one of its most practical ideas concrete: EditorConfig, the small,
editor-agnostic standard that keeps a whole team's formatting consistent. You
create an .editorconfig file with the standard rules and run a real checker
that reports which files obey the rules and which break them — the same kind
of check that editors and continuous-integration pipelines run for you.
Learning objectives
- Write an
.editorconfigfile with the six standard keys and say what each enforces. - Explain the difference between personal editor settings and a shared
.editorconfig. - Run an editor-agnostic checker that detects tabs-versus-spaces, trailing whitespace, and a missing final newline.
- Complete a working script by filling in four well-specified exercises.
- Record your own editor choice and configuration on a worksheet you keep for later lessons.
Prerequisites
- The Day 36 lesson (read it first — it explains editors, settings, and EditorConfig).
- A terminal and basic comfort running
bashscripts (from the earlier lessons in this section). - Any code editor to view and edit the files (this lab is where you put one to use).
Supported operating systems
- macOS — fully supported (tested on macOS with Apple Silicon).
- Linux — fully supported (any distribution with
bash,awk,grep,mktemp). - Windows — run the scripts inside WSL (Windows Subsystem for Linux); the plain Windows shell is not supported for this lab.
Hardware requirements
Any computer made in roughly the last 15 years. The lab creates a few tiny text files in a temporary directory and reads them; it needs no meaningful RAM, disk, or GPU.
Required software
bash(3.2 or newer — preinstalled on macOS and Linux).- Standard POSIX utilities only:
awk,grep,printf,tail,mktemp,basename. All preinstalled. - No editor extension or plugin is required to run the lab, though you will configure an editor as part of the practice assignment.
Free and open-source options
Everything here is free. bash and every utility used are open-source or ship
with your OS, and EditorConfig itself is an open standard supported by many
free editors (VS Code, Vim/Neovim, Zed, and more, some via a free plugin). No
account, API key, or purchase is needed.
Installation
None. Copy or clone this directory and change into it:
cd labs/sections/computing-foundations/day-036-choosing-and-configuring-a-code-editor
File structure
day-036-choosing-and-configuring-a-code-editor/
├── README.md ← you are here
├── metadata.yml ← machine-readable lab metadata
├── starter/
│ ├── editorconfig_demo.sh ← YOUR working file (4 exercises)
│ └── editor-worksheet.md ← worksheet for the practice assignment
├── examples/
│ └── editorconfig_demo.sh ← completed reference implementation
├── tests/
│ └── run_tests.sh ← automated checks
├── expected-output/
│ ├── sample-run.txt ← real captured run of the demo
│ └── FIELDS.md ← which output lines are stable vs machine-specific
├── requirements/
│ └── README.md ← dependency statement (none beyond the OS)
├── troubleshooting.md
└── security.md
How to run
From this directory:
## 1. See the finished result first
bash examples/editorconfig_demo.sh
## 2. Your task: complete the four exercises in the starter, then run it
bash starter/editorconfig_demo.sh
## 3. Check your work
bash tests/run_tests.sh
What the commands do
bash examples/editorconfig_demo.sh— runs the reference script: it creates a temporary sample project with one clean file and three messy ones (tab-indented, trailing whitespace, missing final newline), writes an.editorconfigwith the six standard rules, checks every file against those rules usingawk/grep/tail, prints a report, and deletes the temporary project on exit.bash starter/editorconfig_demo.sh— the same skeleton with fourFILL-INplaceholders. Each exercise comment names the exact line to write: (1) the six.editorconfigrules, (2) a call to check a file, (3) a fix for the trailing-whitespace file, (4) a re-check to verify the fix. Edit the file in your editor and replace each placeholder.bash tests/run_tests.sh— verifies that the demo writes an.editorconfigcontaining all six required keys and that its checker detects the trailing-whitespace, missing-final-newline, and tab violations while passing the clean file; exits 0 on success, non-zero on any failure, so it can run in CI.
Expected output
See expected-output/sample-run.txt — a real captured run:
=== EditorConfig demo ===
Created sample project in: /tmp/editorconfig-demo.XXXXXX
Wrote .editorconfig with 6 rules.
Checking files against .editorconfig ...
clean.py ............ OK
tabs.py ............. VIOLATION: uses tabs (indent_style = space)
trailing.py ......... VIOLATION: trailing whitespace on 2 line(s)
no_newline.py ....... VIOLATION: missing final newline
3 file(s) with violations, 1 clean.
Cleaning up temporary project.
Only the temporary path on the second line changes between runs and machines;
expected-output/FIELDS.md explains exactly which
lines are stable.
Validation steps
- Run
bash examples/editorconfig_demo.sh— it must print the report and exit without error. - Complete the four exercises in
starter/editorconfig_demo.sh, then run it — the "after the fix" check must reporttrailing.py ... OK. - Confirm your starter no longer contains any
FILL-INplaceholder. - Run the tests (next section) — all checks must pass.
Tests
bash tests/run_tests.sh
Expected final line: 12 checks, 0 failure(s). (six checks that the demo
writes each required .editorconfig key, and six that its checker correctly
classifies the four sample files). If you have completed the starter, the
tests additionally run it and confirm your fix. The command exits 0 on success
and non-zero on any failure.
Cleanup
Nothing to clean up: both scripts write only into a temporary directory that
they delete automatically on exit (via a trap), and they make no network
calls and change no settings. To reset your work, restore the starter from
git: git checkout -- starter/editorconfig_demo.sh.
Troubleshooting
See troubleshooting.md for the full list (wrong directory, permission messages, missing utilities, WSL notes, and what to do if the checker reports no violations).
Security notes
See security.md. Short version: the scripts run no network calls, need no elevated privileges, and write only to a self-deleting temporary directory — but read them first, as you should with any script.
Extension exercises
- Add a
[*.md]section to the.editorconfigthat setstrim_trailing_whitespace = false(Markdown uses two trailing spaces to mean a line break), and confirm the checker or your editor now treats Markdown differently from code. - Extend the checker to also flag files that use more than two spaces of indentation, mirroring
indent_size = 2. - Install the EditorConfig support for your editor (built in for some, a free plugin for others), open the sample files, and watch your editor enforce the same rules the checker reports.
Navigation
- Previous day: Day 35 — Git Workflows for Real Projects (
labs/sections/computing-foundations/day-035-git-workflows-for-real-projects/). - Next day: Day 37 — Debuggers, Linters, and Formatters (
labs/sections/computing-foundations/day-037-debuggers-linters-and-formatters/, to be written).
Expected output
FIELDS.md
# Expected output — what is stable and what varies
`sample-run.txt` in this directory is a real captured run of
`examples/editorconfig_demo.sh` (macOS, bash, 2026-07-12). A correct run on
any platform prints, in order:
1. `=== EditorConfig demo ===`
2. `Created sample project in: <path>` — the `<path>` is a temporary
directory created by `mktemp`, so it **differs on every run and machine**
(for example `/tmp/editorconfig-demo.XXXXXX` on Linux, or a
`/var/folders/.../T/...` path on macOS). Only the path varies; the label
is fixed.
3. `Wrote .editorconfig with 6 rules.`
4. `Checking files against .editorconfig ...`
5. ` clean.py ............ OK`
6. ` tabs.py ............. VIOLATION: uses tabs (indent_style = space)`
7. ` trailing.py ......... VIOLATION: trailing whitespace on 2 line(s)`
8. ` no_newline.py ....... VIOLATION: missing final newline`
9. `3 file(s) with violations, 1 clean.`
10. `Cleaning up temporary project.`
Lines 3–10 are identical on macOS and Linux — the checker uses only POSIX
`awk`, `grep`, `printf`, `tail`, and `mktemp`, which behave the same on both.
The only line that changes between runs is the temporary path on line 2.
The `tests/run_tests.sh` run for this lab ends with the line
`12 checks, 0 failure(s).` and exits 0.
sample-run.txt
=== EditorConfig demo ===
Created sample project in: /var/folders/7j/4qzljp553ndfjm_y6zbygsz00000gn/T//editorconfig-demo.RdAVyX
Wrote .editorconfig with 6 rules.
Checking files against .editorconfig ...
clean.py ............ OK
tabs.py ............. VIOLATION: uses tabs (indent_style = space)
trailing.py ......... VIOLATION: trailing whitespace on 2 line(s)
no_newline.py ....... VIOLATION: missing final newline
3 file(s) with violations, 1 clean.
Cleaning up temporary project.
Source files
examples/editorconfig_demo.sh (3686 bytes)
#!/usr/bin/env bash
# Day 036 lab — completed reference implementation.
#
# Builds a small sample project with deliberately messy files, writes an
# .editorconfig with the standard formatting rules, then checks every file
# against those rules using grep/awk and reports the violations. This is a
# real, editor-agnostic config check: no editor and no network are needed.
#
# The sample project lives in a temporary directory that is deleted on exit,
# so this script writes nothing permanent to your machine.
set -euo pipefail
# --- 1. Create an isolated sample project (cleaned up on exit) ------------
project_dir="$(mktemp -d "${TMPDIR:-/tmp}/editorconfig-demo.XXXXXX")"
cleanup() {
echo "Cleaning up temporary project."
rm -rf "${project_dir}"
}
trap cleanup EXIT
echo "=== EditorConfig demo ==="
echo "Created sample project in: ${project_dir}"
# A clean file: two-space indentation, no trailing whitespace, ends in a newline.
printf 'def greet(name):\n return "Hi " + name\n' >"${project_dir}/clean.py"
# A file indented with a TAB instead of spaces (breaks indent_style = space).
printf 'def greet(name):\n\treturn "Hi " + name\n' >"${project_dir}/tabs.py"
# A file with trailing whitespace on two lines (breaks trim_trailing_whitespace).
printf 'x = 1 \ny = 2 \n' >"${project_dir}/trailing.py"
# A file with NO final newline (breaks insert_final_newline).
printf 'z = 3' >"${project_dir}/no_newline.py"
# --- 2. Write the .editorconfig the whole team would share ----------------
cat >"${project_dir}/.editorconfig" <<'EOF'
root = true
[*]
indent_style = space
indent_size = 2
end_of_line = lf
insert_final_newline = true
trim_trailing_whitespace = true
charset = utf-8
EOF
echo "Wrote .editorconfig with 6 rules."
echo
# --- 3. Check each file against the rules using grep/awk ------------------
# The three checks below mirror three .editorconfig keys:
# indent_style = space -> no leading tabs
# trim_trailing_whitespace -> no trailing spaces/tabs
# insert_final_newline -> file ends with a newline
check_file() {
local file="$1" name violations
name="$(basename "${file}")"
violations=""
# indent_style = space: any line that begins with a tab is a violation.
if awk 'index($0, "\t") == 1 { found = 1 } END { exit !found }' "${file}"; then
violations="uses tabs (indent_style = space)"
fi
# trim_trailing_whitespace: count lines ending in a space or tab.
local trailing
trailing="$(awk '/[ \t]+$/ { c++ } END { print c + 0 }' "${file}")"
if [ "${trailing}" -gt 0 ]; then
if [ -n "${violations}" ]; then violations="${violations}; "; fi
violations="${violations}trailing whitespace on ${trailing} line(s)"
fi
# insert_final_newline: if the last byte is not a newline, it is missing.
if [ -n "$(tail -c 1 "${file}")" ]; then
if [ -n "${violations}" ]; then violations="${violations}; "; fi
violations="${violations}missing final newline"
fi
# Report, padded with dots so the columns line up.
printf ' %s ' "${name}"
local pad=$((20 - ${#name}))
while [ "${pad}" -gt 0 ]; do printf '.'; pad=$((pad - 1)); done
if [ -z "${violations}" ]; then
printf ' OK\n'
return 0
else
printf ' VIOLATION: %s\n' "${violations}"
return 1
fi
}
echo "Checking files against .editorconfig ..."
violation_count=0
clean_count=0
for file in "${project_dir}/clean.py" "${project_dir}/tabs.py" \
"${project_dir}/trailing.py" "${project_dir}/no_newline.py"; do
if check_file "${file}"; then
clean_count=$((clean_count + 1))
else
violation_count=$((violation_count + 1))
fi
done
echo
echo "${violation_count} file(s) with violations, ${clean_count} clean."
metadata.yml (677 bytes)
lesson_id: D036
day: 36
kind: configuration-activity
languages: [bash]
setup_commands:
- cd labs/sections/computing-foundations/day-036-choosing-and-configuring-a-code-editor
run_commands:
- bash examples/editorconfig_demo.sh
- bash starter/editorconfig_demo.sh
test_commands:
- bash tests/run_tests.sh
cleanup_commands:
- '# nothing to clean: the demo writes only to a temp dir it deletes on exit'
- 'git checkout -- starter/editorconfig_demo.sh # optional: reset your work'
requires_network: false
requires_api_key: false
estimated_minutes: 30
last_executed: '2026-07-12'
executed_on: 'macOS (Apple Silicon), bash tests/run_tests.sh → 12 checks, 0 failure(s)'
requirements/README.md (871 bytes)
# Dependencies — Day 036 lab
**None beyond a POSIX shell and standard utilities.** This lab intentionally
has zero installable dependencies:
- `bash` ≥ 3.2 (preinstalled on macOS and every mainstream Linux distribution).
- Standard POSIX utilities: `awk`, `grep`, `printf`, `tail`, `mktemp`,
`basename`, `rm` — all part of the base system.
- **Any editor** to view and edit the files. The lab is where you put the
editor you chose in the lesson to use, but no specific editor is required to
run the scripts, and no extension or plugin is needed for the checker.
There is deliberately no `requirements.txt`/`package.json` here; the lab must
run on a factory-fresh machine. EditorConfig support in an editor (built in for
some, a free plugin for others) is optional and only needed for the extension
exercise that watches your editor enforce the rules live.
starter/editor-worksheet.md (1507 bytes)
# Editor worksheet — Day 036
Fill this in as you choose and configure your editor. Keep it: a later lesson
on debuggers, linters, and formatters builds on the editor you set up today.
## 1. Which editor do you use?
- **Editor:** _(for example: Visual Studio Code)_
- **Why this one?** _(1–2 sentences: free/paid, platform, what pulled you to it)_
- **Cost:** _(free / free tier / paid — state which)_
## 2. Three settings you configured (and why)
For each, name the setting and the concrete reason it helps you.
| # | Setting (name or key) | Value you chose | Why it helps |
| - | --------------------- | --------------- | ------------ |
| 1 | _(e.g. editor.tabSize)_ | _(e.g. 2)_ | _(e.g. matches this course's .editorconfig)_ |
| 2 | | | |
| 3 | | | |
## 3. What does your .editorconfig enforce?
List the rules in the project's `.editorconfig` and what each one guarantees:
- `indent_style = ` _____ → _(tabs or spaces for indentation)_
- `indent_size = ` _____ → _(how many columns per indent level)_
- `end_of_line = ` _____ → _(line-ending style)_
- `insert_final_newline = ` _____ → _(every file ends with a newline)_
- `trim_trailing_whitespace = ` _____ → _(no stray spaces at line ends)_
- `charset = ` _____ → _(text encoding)_
## 4. Reflection
In two or three sentences, describe how using your editor's search and
multi-cursor (or find-and-replace) features to rename a variable felt,
compared with making the same edit in a plain text editor.
_(your answer here)_
starter/editorconfig_demo.sh (3622 bytes)
#!/usr/bin/env bash
# Day 036 lab — YOUR working file.
#
# Complete the four numbered exercises below. Each one names the exact lines
# to write. The completed reference version is in
# examples/editorconfig_demo.sh — run that first to see the goal, then do
# these yourself. When you are finished, run: bash tests/run_tests.sh
#
# The sample project is built in a temporary directory and deleted on exit,
# so nothing permanent is written to your machine.
set -euo pipefail
project_dir="$(mktemp -d "${TMPDIR:-/tmp}/editorconfig-starter.XXXXXX")"
cleanup() { rm -rf "${project_dir}"; }
trap cleanup EXIT
echo "=== EditorConfig starter ==="
echo "Sample project: ${project_dir}"
# A clean file (correct already) and three messy ones to check against rules.
printf 'def greet(name):\n return "Hi " + name\n' >"${project_dir}/clean.py"
printf 'def greet(name):\n\treturn "Hi " + name\n' >"${project_dir}/tabs.py"
printf 'x = 1 \ny = 2 \n' >"${project_dir}/trailing.py"
printf 'z = 3' >"${project_dir}/no_newline.py"
# A reusable checker (already written for you) — it reports whether a file
# obeys indent_style = space, trim_trailing_whitespace, and insert_final_newline.
check_file() {
local file="$1" name violations trailing pad
name="$(basename "${file}")"
violations=""
if awk 'index($0, "\t") == 1 { found = 1 } END { exit !found }' "${file}"; then
violations="uses tabs (indent_style = space)"
fi
trailing="$(awk '/[ \t]+$/ { c++ } END { print c + 0 }' "${file}")"
if [ "${trailing}" -gt 0 ]; then
[ -n "${violations}" ] && violations="${violations}; "
violations="${violations}trailing whitespace on ${trailing} line(s)"
fi
if [ -n "$(tail -c 1 "${file}")" ]; then
[ -n "${violations}" ] && violations="${violations}; "
violations="${violations}missing final newline"
fi
printf ' %s ' "${name}"
pad=$((20 - ${#name})); while [ "${pad}" -gt 0 ]; do printf '.'; pad=$((pad - 1)); done
if [ -z "${violations}" ]; then printf ' OK\n'; return 0
else printf ' VIOLATION: %s\n' "${violations}"; return 1; fi
}
# ---------------------------------------------------------------------------
# Exercise 1: WRITE AN .editorconfig RULE.
# Inside the [*] section below, replace the single placeholder line with the
# six standard rules, one per line:
# indent_style = space
# indent_size = 2
# end_of_line = lf
# insert_final_newline = true
# trim_trailing_whitespace = true
# charset = utf-8
cat >"${project_dir}/.editorconfig" <<'EOF'
root = true
[*]
FILL-IN-EX1
EOF
echo "Wrote .editorconfig."
echo
# ---------------------------------------------------------------------------
# Exercise 2: CHECK A FILE against the rules.
# Replace the placeholder below so it calls the checker on the trailing file:
# check_file "${project_dir}/trailing.py"
echo "Checking trailing.py before the fix:"
FILL-IN-EX2 || true
echo
# ---------------------------------------------------------------------------
# Exercise 3: FIX A VIOLATION.
# Rewrite trailing.py without the trailing spaces. Replace the placeholder
# below with:
# printf 'x = 1\ny = 2\n' >"${project_dir}/trailing.py"
FILL-IN-EX3
echo "Fixed trailing.py."
echo
# ---------------------------------------------------------------------------
# Exercise 4: VERIFY the fix.
# Check trailing.py again — it should now report OK. Replace the placeholder
# below with:
# check_file "${project_dir}/trailing.py"
echo "Checking trailing.py after the fix:"
FILL-IN-EX4
echo
echo "Done. Compare your run with examples/editorconfig_demo.sh."
tests/run_tests.sh (3395 bytes)
#!/usr/bin/env bash
# Tests for the Day 036 lab. Run from the lab directory:
# bash tests/run_tests.sh
#
# Verifies that the reference demo writes an .editorconfig with the required
# keys and that its checker detects the known trailing-whitespace and
# missing-final-newline violations (and the tab and clean cases too). If the
# learner has finished the starter, it is held to the same standard.
# No network, no privileges, writes nothing outside temp dirs.
set -u
lab_dir="$(cd "$(dirname "${BASH_SOURCE[0]}")/.." && pwd)"
example="${lab_dir}/examples/editorconfig_demo.sh"
starter="${lab_dir}/starter/editorconfig_demo.sh"
failures=0
checks=0
check() {
local label="$1" ok="$2"
checks=$((checks + 1))
if [ "${ok}" = "yes" ]; then
echo " ok: ${label}"
else
echo " FAIL: ${label}"
failures=$((failures + 1))
fi
}
# --- The .editorconfig the demo writes must contain the required keys -----
echo "Checking the demo defines all required .editorconfig keys ..."
for key in indent_style indent_size end_of_line insert_final_newline \
trim_trailing_whitespace charset; do
if grep -q "^${key} = " "${example}"; then
check "demo writes '${key}' rule" "yes"
else
check "demo writes '${key}' rule" "no"
fi
done
# --- The checker must detect the known violations -------------------------
run_checker_checks() {
local script="$1" output
echo "Running ${script##*/} and inspecting its report ..."
if ! output="$(bash "${script}" 2>&1)"; then
check "${script##*/} exits successfully" "no"
echo "${output}" | sed 's/^/ /'
return
fi
check "${script##*/} exits successfully" "yes"
echo "${output}" | grep -Eq 'Wrote .editorconfig' \
&& check "reports the .editorconfig was written" "yes" \
|| check "reports the .editorconfig was written" "no"
echo "${output}" | grep -Eq 'trailing\.py .*VIOLATION: trailing whitespace on 2 line' \
&& check "detects the trailing-whitespace violation" "yes" \
|| check "detects the trailing-whitespace violation" "no"
echo "${output}" | grep -Eq 'no_newline\.py .*VIOLATION: missing final newline' \
&& check "detects the missing-final-newline violation" "yes" \
|| check "detects the missing-final-newline violation" "no"
echo "${output}" | grep -Eq 'tabs\.py .*VIOLATION: uses tabs' \
&& check "detects the tab-indentation violation" "yes" \
|| check "detects the tab-indentation violation" "no"
echo "${output}" | grep -Eq 'clean\.py .*OK' \
&& check "passes the clean file" "yes" \
|| check "passes the clean file" "no"
}
run_checker_checks "${example}"
# The starter ships with FILL-IN placeholders; once the learner has replaced
# them all, run and inspect their version too.
if grep -q 'FILL-IN' "${starter}"; then
echo "Note: starter still has FILL-IN exercises — skipping its run (structure only)."
else
echo "Running the completed starter and inspecting its report ..."
if out="$(bash "${starter}" 2>&1)"; then
check "completed starter exits successfully" "yes"
echo "${out}" | grep -Eq 'trailing\.py .*OK' \
&& check "starter's fix makes trailing.py clean" "yes" \
|| check "starter's fix makes trailing.py clean" "no"
else
check "completed starter exits successfully" "no"
echo "${out}" | sed 's/^/ /'
fi
fi
echo
echo "${checks} checks, ${failures} failure(s)."
[ "${failures}" -eq 0 ]
Troubleshooting
Troubleshooting — Day 036 lab
No such file or directory when running a script
You are not in the lab directory. Change into it first, then run the command:
cd labs/sections/computing-foundations/day-036-choosing-and-configuring-a-code-editor
bash examples/editorconfig_demo.sh
Permission denied when running the script
Run it through bash explicitly rather than as ./examples/...:
bash examples/editorconfig_demo.sh
That avoids needing the executable bit. If you prefer ./examples/..., first
run chmod +x examples/editorconfig_demo.sh.
The checker reports no violations at all
The sample files or the .editorconfig were not created. Re-run the demo from
a clean state and confirm it prints the Wrote .editorconfig line before the
checking section. If you are running the starter, make sure you have
completed Exercise 1 (the six .editorconfig rules) — an empty rule set means
nothing to check against.
command not found: awk (or grep, mktemp)
These ship with macOS and every mainstream Linux distribution. If one is
missing you are on an unusually stripped-down system (a minimal container, for
example) — install the base utilities (apt install coreutils gawk grep on
Debian/Ubuntu) and retry.
The tests say a starter check failed
Search your starter/editorconfig_demo.sh for the word FILL-IN: any that
remain mark an unfinished exercise. Complete all four, save, and re-run
bash tests/run_tests.sh. If Exercise 3 is wrong, the "after the fix" line
will still report a violation instead of OK — re-read the exact printf
line named in the exercise comment.
Windows: bash is not recognized
Use WSL (wsl --install, then open Ubuntu and follow the commands unchanged).
The plain Windows Command Prompt and PowerShell do not run these bash scripts.
The temporary path in the output looks different from the sample
That is expected. The path after Created sample project in: is a fresh
mktemp directory, so it differs on every run and machine. Only that one line
varies; see expected-output/FIELDS.md.
Security notes
Security notes — Day 036 lab
- What the scripts do: create a handful of tiny text files in a temporary
directory (made with
mktemp), write an.editorconfig, read the files back withawk/grep/tail, print a report, and delete the temporary directory on exit. They make no network connections, need no elevated privileges, and write nothing outside that self-deleting temp dir. - Temp dir only: all file creation happens under your system temp location
(
$TMPDIRor/tmp). The scripts never touch your home directory, the repository, or any project of yours. Atrap ... EXITremoves the temp directory even if the script is interrupted. - Privileges: everything runs as your normal user. Nothing here needs
sudo; if any tutorial ever asks you tosudoa script you have not read, that is your cue to stop and read it first. - Reading before running: both scripts are short and commented — read them before running. Running unread shell scripts is a common way developers get compromised, and this course's habit is that every lab script is small enough to read and understand first.