Source: https://mayphus.org/systems-observation/
Title: Systems learning starts with an observation
Metadata: {"kind":"page","language":"en","route":"/systems-observation/","tags":["learning","systems","shell"],"type":"page"}

# Systems learning starts with an observation

[Guide and chapter map](/understanding-computer-systems/) · Next: [files and permissions](/systems-linux-files/) or [FreeBSD inspection](/systems-freebsd-base/)

## Learning goal

Distinguish what you asked a system to do, what you observed, and what remains unknown. By the end, you should be able to explain where a shell command gets its input, where its output goes, and why a successful command is a narrower claim than “the computer works.”

## Follow one boundary at a time

A terminal displays text and accepts input. A shell interprets command syntax. Some operations are built into the shell; others start programs. A running program is a process. Processes ask the kernel to open files, allocate resources and communicate. Storage, network interfaces and other devices add further boundaries.

These distinctions help locate a failure. A typo can fail before a program starts. A valid program can be denied access to a file. A file can exist on a different mounted filesystem than expected. A process can run while its service is unhealthy. An error message should narrow the next question, not trigger a random repair.

In shell syntax, quotation marks preserve an argument containing spaces. A redirect such as `>` makes the shell open the destination for output; it can overwrite an existing file. A pipe connects one command's output to another command's input. These are reasons to understand a command before pasting it, especially when it writes. [Ubuntu's shell tutorial](https://ubuntu.com/desktop/docs/en/latest/tutorial/the-linux-command-line-for-beginners/) develops these basics with interactive examples.

## A complete disposable exercise

**Executed environment:** Ubuntu 26.04.1 LTS, GNU Bash 5.3.9, 8 October 2026. This is a Linux exercise using GNU tools, not a FreeBSD command block. It needs only the normal account and the existing `mktemp`, `wc`, `stat`, `cat`, `rm` and `rmdir` commands. It creates one new temporary directory and one synthetic text file, then removes those exact two objects. It does not inspect personal files or change system settings.

Run the whole block in Bash. Do not substitute a real directory or document. The parentheses contain the variables and permission mask within a subshell; the rest of your terminal session retains its earlier settings. `set -eu` stops the block after an error or an unset-variable use.

```bash
(
  set -eu
  umask 077
  lesson_dir=$(mktemp -d /tmp/systems-lesson.XXXXXX)
  printf 'first observation\nsecond observation\n' > "$lesson_dir/notes.txt"
  printf 'Lines: '
  wc -l < "$lesson_dir/notes.txt"
  printf 'Bytes: '
  wc -c < "$lesson_dir/notes.txt"
  printf 'Mode: '
  stat -c '%a' -- "$lesson_dir/notes.txt"
  cat -- "$lesson_dir/notes.txt"
  rm -- "$lesson_dir/notes.txt"
  rmdir -- "$lesson_dir"
)
```

The measured result was:

```text
Lines: 2
Bytes: 37
Mode: 600
first observation
second observation
```

The generated temporary suffix is intentionally absent from the output. `wc` receives an already-open file through standard input, so it reports a count without printing the file's pathname. The two newline characters are included in the 37-byte count. The ASCII contents make bytes and visible characters easy to reason about here; that relationship changes with multibyte text.

The file mode was `600`: ordinary mode bits gave its owner read and write access and gave no permissions to the group or others. The temporary directory and restrictive mask constrain this toy file; they are not a complete security assessment of an operating system. `rm` names only this generated file, and `rmdir` removes only the now-empty generated directory. There is no recursive deletion. If the block stops early, it may leave a small directory under `/tmp`; inspect that specific leftover before deciding whether to remove it. Do not replace cleanup with a broad wildcard command.

## What did the experiment establish?

It established that these tools could create, count, inspect, read and remove this file in that execution environment. It did not establish that a different user's data is readable, that the filesystem survives reboot, that a backup works, or that the same GNU `stat` option exists on FreeBSD.

Write down three separate statements: “I requested two lines,” “the measured count was two,” and “I have not tested persistence.” This small habit scales. In the [R2S investigation](/nanopi-r2s-alpine-boot/), serial silence initially described the whole measurement path. It did not isolate the board as the failed component.

## Keep a compact evidence record

For a later exercise, record the OS/release, the command, its exit status, the relevant output and your next question. Use synthetic data where possible. Before sharing real output, remove account names, addresses, tokens, paths and unrelated log messages. Never publish a whole environment dump as proof that one command ran.

A useful answer often looks like: “The process exists, but I have not checked its listener,” or “The file is on a temporary filesystem, so I have not demonstrated durable storage.” Continue with [storage boundaries](/systems-storage/) to separate those latter claims.

For the exact installed semantics, use the local `man mktemp`, `man wc` and `man stat` pages. Command options are part of the environment being tested, not universal shell syntax.