パート 13

自分のライブラリを作る：役立った作業を持ち運べる技術に変える

ここまで来るとターミナルはコマンド一覧ではなくなります。「この種類の問題はこう調べる」「このファイルはこう変換する」「このプロジェクトはこうパッケージする」「このリリースはこう検証する」「この環境はこう戻す」という、自分が信頼する方法の集合になります。

方法を記憶ではなくライブラリへ保存する

確認、配備、メディア、移行、診断など目的別のフォルダーを作り、実証済みの手順ごとに短いスクリプトやメモを置きます。フォルダー名だけで、半年後の自分が「いつ使う道具か」を思い出せるようにします。

プロジェクト間で持ち運ぶ普通の非公開フォルダだけでも、十分に携帯できる個人環境になります。毎回ゼロから考え直すはずだった小さな判断を、長期にわたって残せます。

cd lil-playground

md library

md library/checks

md library/deploy

md library/media

組み合わせられる小さな手順を選ぶ

良い手順は一つの問いに答えるか、境界の明確な一つの変換を行います。hosting-baseline.lil、package-project.lil、network-check.lil は、設定編集、アップロード、権限変更、データベース操作を全部まとめた巨大スクリプトより信頼しやすいものです。

組み合わせを小さく保つと、リスクも見えたままになります。線形 #lil ファイルは通常のコマンドを呼べ、判断が必要なら run ワークフローから子ワークフローを呼べます。名前、想定する入力、出力を分かりやすく保ちます。

最終ファイルだけでなく差分を記録する

diff は二つのテキスト状態の差を確認可能な変更として表し、パッチとして保存できます。final-final-2.txt のようにコピーを増やすより、変更そのものを確認できる方が役立つ場面は多くあります。

リリース成果物には変更記録と hash を組み合わせます。パッチは何が変わったか、ダイジェストは後でバイト列が同一かを示します。どちらもバックアップの代わりではありませんが、引き継ぎと検証をずっと落ち着いて行えます。

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

小さく正確な補助ツールで不要な使い捨てコードを減らす

rand は安全な整数、トークン、UUIDを生成でき、math は検証された計算や単位変換を行います。ワークフローに正確な一値だけ必要で、一時的な PHP スクリプトを書く方が重い場合に便利です。

暗号学的に安全な乱数も秘密情報の管理システムそのものではなく、計算機能も業務ルールエンジンではありません。小さな補助ツールは小さな仕事に使い、重要な方針はその結果を使うワークフロー側で明示します。

rand -uuid

rand 1 100

math clamp 105 0 100

math round 82.456 1

緊急事態が保守を急務にする前にツールを整える

環境が健康なときに時々 core、doctor -q、upgrade -c を実行します。「正常」がどんな姿かを知り、本番障害の前に更新や不足している依存関係へ気付けます。

保守は退屈なくらいが理想です。リポジトリの信頼性を保ち、変更を確認し、バックアップを残し、このホストだけが他と違う少数のローカル判断を記録します。

core

doctor -q

upgrade -c

環境全体を燃やさず、一つの層だけリセットする方法を知る

clear は画面表示だけを消します。モジュールは個別にアンインストールでき、追加インターフェースも別にリセットできます。Core を残して拡張層だけ外すこともできます。完全な kill は用意されていますが、問題が起きたとき最初に使うものではなく、最後の手段です。

この層ごとのモデルは一般的なターミナル習慣としても有効です。本当に壊れている最小の状態を見極め、それだけをリセットします。破壊は診断の代わりにはなりません。

clear

結果を証明できるワークフローで締めくくる

最後の例は作業領域の存在を確認し、TAR を作り、アーカイブをテストし、成果物を確認し、ダイジェストを計算します。各手順は次の操作に必要な前提条件を整えるか、確認材料を残します。

まず -n、次に -v で実行します。出力を理解してからルートとアーカイブ名を変えてください。目的はこの特定のアーカイブではなく、自分自身で説明できる手順を作る習慣です。

run library/release-check.lil -n

run library/release-check.lil -v

本当に持ち運べるのはコマンドの語彙ではなく、作業の方法

Linux、macOS、Windows、ホスティング環境はそれぞれ異なり、lil-terminal も同一の環境であるかのようには振る舞いません。共通して持ち運べるのは作業の考え方です。現在の状態を確認し、範囲を限定した変更を一つ行い、結果を検証し、再現できる手順を残します。

この考え方が自然になると、新しいターミナルは未知の構文の壁ではなくなります。尋ねるべき問い、集める確認材料、環境に合わせて調整できる手順をすでに持っているからです。この入門の目的は学習を終えることではなく、コマンドラインを「自分が仕事をできる場所」に変えることです。

スクリプトとして残す

最後のワークフローを library/release-check.lil として保存します。これは特定の業務プロジェクトに依存せず、作業領域を検証し、アーカイブを作り、テストし、内容を確認し、ダイジェストを記録する再利用可能なリリース確認手順です。

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