Part 13

Build a personal library: turn useful work into transferable craft

At this point the terminal stops being a list of commands. It becomes a collection of methods you trust: inspect this kind of problem, transform that kind of file, package this project, verify that release, rebuild this environment.

Store methods in a library instead of storing them in memory

Create folders by purpose — checks, deploy, media, migration, diagnostics — and keep a short script or note for each proven routine. The directory names should explain when you would reach for the tool six months from now.

A plain private folder copied between projects is already a portable personal environment. It preserves years of small decisions that would otherwise be rediscovered from scratch.

cd lil-playground

md library

md library/checks

md library/deploy

md library/media

Prefer small recipes that compose

A good routine answers one question or performs one bounded transformation. hosting-baseline.lil, package-project.lil and network-check.lil are easier to trust than one enormous script that edits configuration, uploads files, changes permissions and touches a database at once.

Composition keeps risk visible. A linear #lil file can call ordinary commands; a run workflow can call child workflows when decisions are needed. Keep names, expected inputs and outputs obvious.

Record the difference, not just the final file

diff turns two text states into a reviewable change and can save a patch. That is often more informative than a second copy named final-final-2.txt, because the change itself becomes inspectable.

Pair change records with hash for release artifacts. A patch explains what changed; a digest tells you whether the bytes are still identical later. Neither replaces a backup, but together they make handoffs and verification much calmer.

echo "status=review" > library/routine-v1.txt -r

echo "status=done" > library/routine-v2.txt -r

diff library/routine-v1.txt library/routine-v2.txt

diff library/routine-v1.txt library/routine-v2.txt -o library/routine.patch

Small exact utilities prevent unnecessary one-off code

rand can generate secure integers, tokens and UUIDs; math handles validated calculations and conversions. They are useful when a workflow needs one exact value and writing a temporary PHP script would add more surface than value.

A cryptographically secure random value is still not a secret-management system, and a calculator is not a business-rule engine. Use small utilities for small jobs and keep important policy explicit in the workflow that uses the result.

rand -uuid

rand 1 100

math clamp 105 0 100

math round 82.456 1

Maintain the tool before an emergency makes maintenance urgent

Occasionally run core, doctor -q and upgrade -c when the environment is healthy. You learn what “normal” looks like and notice updates or missing dependencies before a production incident.

Maintenance is easier when it is boring. Keep the repository trusted, review changes, preserve backups and record the few local decisions that make this host different from another.

core

doctor -q

upgrade -c

Know how to reset one layer without burning the whole environment

clear resets only what you see. Modules can be uninstalled individually. The optional interface can be reset separately. The extension layer can be removed while Core remains. Full kill exists, but it is the last boundary, not a troubleshooting reflex.

This layered model is a useful terminal habit in general: identify the smallest state that is actually broken and reset only that state. Destruction is rarely a substitute for diagnosis.

clear

Finish with a workflow whose result can be proved

The final example checks that the workspace exists, archives it, tests the TAR, inspects the artifact and calculates a digest. Every step either establishes a precondition or produces evidence for the next step.

Run it with -n first, then -v. Change the root and archive names only after you understand the output. The goal is not this particular archive — it is the habit of building procedures that explain themselves.

run library/release-check.lil -n

run library/release-check.lil -v

The real skill is the method, not the command vocabulary

Linux, macOS, Windows and hosting runtimes are not the same, and lil-terminal is not pretending they are. What transfers is the culture: inspect the current state, make a bounded change, verify the result, then save the repeatable part.

Once that feels natural, a new terminal is no longer a wall of unfamiliar syntax. You have questions to ask, evidence to collect and routines to adapt. That is the point of this introduction: not to finish learning, but to make the command line feel like a place where you can work.

Keep this as a script

Save the final workflow as library/release-check.lil. It does not know your business project: it demonstrates the reusable shape of a release checkpoint — verify the workspace, create an archive, test it, inspect it and record a digest.

set root lil-playground
set archive lil-playground-checkpoint.tar

if dir "$root"
    dir "$root" 1 -G
    tar "$root" "$archive" -f
    tar "$archive" -t
    stat "$archive"
    hash "$archive"
else
    stop "Workspace is missing"
end