Computing FoundationsSystems Foundations: Storage, Observability, and Tooling › Day 36

Hands-on lab — Day 36: 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

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 .editorconfig file 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 bash scripts (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 .editorconfig with the six standard rules, checks every file against those rules using awk/grep/tail, prints a report, and deletes the temporary project on exit.
  • bash starter/editorconfig_demo.sh — the same skeleton with four FILL-IN placeholders. Each exercise comment names the exact line to write: (1) the six .editorconfig rules, (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 .editorconfig containing 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

  1. Run bash examples/editorconfig_demo.sh — it must print the report and exit without error.
  2. Complete the four exercises in starter/editorconfig_demo.sh, then run it — the "after the fix" check must report trailing.py ... OK.
  3. Confirm your starter no longer contains any FILL-IN placeholder.
  4. 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

  1. Add a [*.md] section to the .editorconfig that sets trim_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.
  2. Extend the checker to also flag files that use more than two spaces of indentation, mirroring indent_size = 2.
  3. 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.
  • 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 with awk/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 ($TMPDIR or /tmp). The scripts never touch your home directory, the repository, or any project of yours. A trap ... EXIT removes 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 to sudo a 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.