Partie 13

Construire une bibliothèque personnelle : transformer le travail utile en savoir-faire transférable

À ce stade, le terminal n’est plus une liste de commandes. Il devient une collection de méthodes fiables : ainsi j’inspecte ce problème, ainsi je transforme ces fichiers, ainsi je j’empaquette ce projet, ainsi je vérifie un version publiée, ainsi je reconstruis cet environnement.

Stocker les méthodes dans une bibliothèque plutôt que dans la mémoire

Créez des dossiers par objectif — checks, deploy, media, migration, diagnostics — et gardez un script ou une note courte pour chaque routine validée. Le nom du dossier doit expliquer quand vous chercherez cet outil dans six mois.

Un simple dossier privé copié d’un projet à l’autre constitue déjà un environnement personnel portable. Il conserve des années de petites décisions qu’il faudrait autrement redécouvrir.

cd lil-playground

md library

md library/checks

md library/deploy

md library/media

Préférer de petites recettes qui se composent

Une bonne routine répond à une question ou effectue une transformation bornée. hosting-baseline.lil, package-project.lil et network-check.lil inspirent plus confiance qu’un énorme script qui édite la configuration, upload des fichiers, change les permissions et touche une base en même temps.

La composition garde le risque visible. Un fichier linéaire #lil appelle des commandes ordinaires ; un flux de travail run peut appeler des flux de travail enfants si des décisions sont nécessaires. Gardez noms, inputs attendus et outputs évidents.

Enregistrer la différence, pas seulement le fichier final

diff transforme deux états texte en changement lisible et peut enregistrer un patch. C’est souvent plus informatif qu’une copie final-final-2.txt, car le changement lui-même devient inspectable.

Associez les changements à hash pour les artefacts de version publiée. Un patch explique ce qui a changé ; un empreinte dit plus tard si les octets sont toujours identiques. Aucun ne remplace un sauvegarde, mais ensemble ils simplifient transmission et vérification.

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

De petits utilitaires exacts évitent du code jetable inutile

rand peut générer entiers sûrs, tokens et UUID ; math réalise calculs et conversions validés. Ils sont utiles lorsqu’un flux de travail a besoin d’une valeur précise et qu’un script PHP temporaire ajouterait plus de surface que de valeur.

Une valeur aléatoire cryptographiquement sûre n’est pas un système de gestion de secrets, et une calculatrice n’est pas un moteur de règles métier. Utilisez les petits outils pour les petits travaux et gardez les politiques importantes explicites dans le flux de travail.

rand -uuid

rand 1 100

math clamp 105 0 100

math round 82.456 1

Entretenir l’outil avant qu’une urgence rende la maintenance urgente

Lancez parfois core, doctor -q et upgrade -c quand tout va bien. Vous apprenez ainsi à quoi ressemble la normale et remarquez des mises à jour ou dépendances manquantes avant un incident de production.

La maintenance est plus facile lorsqu’elle est ennuyeuse. Accordez votre confiance au dépôt consciemment, relisez les changements, préservez les sauvegardes et notez les quelques décisions locales qui différencient cet hôte d’un autre.

core

doctor -q

upgrade -c

Savoir réinitialiser une couche sans brûler tout l’environnement

clear réinitialise seulement l’affichage. Les modules se désinstallent individuellement. L’interface optionnelle peut être remise à zéro séparément. La couche d’extensions peut disparaître en laissant Core. Le kill complet existe, mais c’est la dernière frontière, pas un réflexe de dépannage.

Ce modèle en couches est une bonne habitude de terminal en général : identifiez le plus petit état réellement cassé et réinitialisez uniquement celui-ci. La destruction remplace rarement le diagnostic.

clear

Terminer par un flux de travail dont le résultat peut être prouvé

L’exemple final vérifie l’existence du workspace, l’archive, teste le TAR, inspecte l’artefact et calcule un empreinte. Chaque étape établit une précondition ou produit une preuve pour la suivante.

Exécutez-le d’abord avec -n, puis avec -v. Ne changez root et archive qu’après avoir compris le résultat. Le but n’est pas cette archive précise, mais l’habitude de construire des procédures qui s’expliquent elles-mêmes.

run library/release-check.lil -n

run library/release-check.lil -v

La vraie compétence est la méthode, pas le vocabulaire des commandes

Linux, macOS, Windows et les environnements d’exécution d’hébergement ne sont pas identiques, et lil-terminal ne prétend pas le contraire. Ce qui se transfère, c’est la méthode : inspecter l’état, effectuer un changement limité, vérifier le résultat puis conserver la partie répétable.

Quand cela devient naturel, un nouveau terminal n’est plus un mur de syntaxe inconnue. Vous avez déjà des questions à poser, des preuves à collecter et des routines à adapter. C’est le but de cette introduction : non pas finir d’apprendre, mais faire de la ligne de commande un endroit où vous savez travailler.

Conservez ceci comme script

Enregistrez le flux de travail final sous library/release-check.lil. Il ne connaît pas votre projet métier : il montre la forme réutilisable d’un checkpoint de version publiée — vérifier le workspace, créer l’archive, la tester, l’inspecter et enregistrer un empreinte.

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