Introduzione

Parte 11

Dalla sequenza al flusso di lavoro: lasciate che `.lil` prenda decisioni

Uno script lineare è perfetto finché la risposta è sempre «fai A, poi B, poi C». Quando serve verificare una directory, riutilizzare un percorso, conservare un risultato o fermarsi con una ragione chiara, state costruendo un flusso di lavoro e non una semplice lista.

Usate il linguaggio di automazione più piccolo che risolve il compito

Un file che inizia con #lil appartiene al esecuzione lineare del Core: i comandi normali vengono eseguiti in ordine e questa semplicità è un vantaggio. È ideale per liste di preparazione, diagnostica ripetibile e procedure brevi.

run è il livello successivo. Aggiunge variabili, condizioni, acquisizione del risultato, script annidati e una politica esplicita in caso di errore. Non trasformate ogni ricetta di tre righe in un programma: passate a run quando il flusso di lavoro richiede davvero stato o decisioni.

install run
help run

Le variabili trasformano path copiati in intenzioni nominate

set root lil-playground assegna un ruolo a un path. Poi $root, $source e $archive dicono che cosa significano i valori invece di costringervi a modificare lo stesso literal in cinque punti.

Buoni nomi rendono uno script portabile. Tenete in alto i valori specifici dell’ambiente, fuori i segreti e preferite poche variabili chiare a costruzioni di stringhe troppo furbe.

Inizia il file così
set root lil-playground
set source lil-playground/project
set archive lil-playground/project.zip

Una condition deve proteggere un’assunzione

if dir "$source" non è decorazione: impedisce al passo di archiviazione di lavorare silenziosamente sul target sbagliato. Le condizioni sono più preziose intorno ad assunzioni il cui errore diventerebbe distruttivo o confuso.

run supporta exists, file, dir, empty, eq, ne, ok, fail e command, con not per invertire. Tenete i rami abbastanza brevi da capire ancora perché esiste ogni percorso.

Inizia il file così
if dir "$source"
    stat "$source"
else
    stop "Project directory is missing"
end

Acquisite il risultato quando la decisione successiva dipende da esso

capture name <command> esegue un normale comando lil e salva il risultato plain in una variabile. Built-in come $last, $status, $cwd e $line espongono il comune stato di esecuzione.

Non catturate tutto solo perché potete. Il testo del terminale è utile quando è piccolo e stabile; file strutturati o comandi di formato dedicati sono migliori se i dati devono sopravvivere tra strumenti o nel tempo.

Inizia il file così
capture current pwd -s
if empty "$current"
    stop "Current directory is unavailable"
end

Decidete che cosa significa un errore prima di automatizzare

Per impostazione predefinita, run si ferma al primo errore: un comando fallito interrompe il flusso di lavoro. -k continua dopo gli errori e va usato solo quando i passaggi indipendenti possono davvero proseguire in sicurezza. stop permette di terminare con una ragione comprensibile.

Eseguite flusso di lavoro sconosciuti prima con -n. Il esecuzione di prova valida ed espande i comandi senza eseguirli; -v mostra poi l’risultato completo durante il run reale. La previsione non è burocrazia: mantiene comprensibile l’automazione.

run workflow.lil -n
run workflow.lil -v

Dividete i flussi di lavoro grandi per responsabilità, non per numero di righe

Un flusso di lavoro può chiamare run child.lil nello stesso contesto di variabili, così le routine di backup, validazione o distribuzione restano indipendenti e riutilizzabili. Mantenete poco profondo l’annidamento e assegnate a ogni file uno scopo chiaro.

run -p crea una rappresentazione compressa protetta da checksum per il trasporto. Packed .lil non è encryption: protegge formato e integrità da modifiche accidentali, non confidenzialità o paternità.

run -p workflow.lil workflow.packed.lil
run workflow.packed.lil

L’automazione ha volutamente meno privilegi di una persona interattiva

I comandi UI interattivi sono bloccati nei flusso di lavoro normali e comandi non interattivi privilegiati come php e ses richiedono -x esplicito. Anche l’auto-install interattivo tramite @command viene rifiutato dentro gli script run.

Questa frizione è intenzionale. Un flusso di lavoro riproducibile deve dichiarare le proprie dipendenze di moduli prima dell’esecuzione e non deve installare codice, chiedere segreti o distruggere il terminale inaspettatamente a metà run.

Conservalo come script

Salvate questo come workflow.lil, create lil-playground/project se volete provare il ramo di successo e lanciatelo prima con run workflow.lil -n. Il passaggio importante è che lo script controlla le proprie assunzioni prima di creare l’archivio.

set root lil-playground
set source lil-playground/project
set archive lil-playground/project.zip

if not dir "$root"
    stop "lil-playground is missing"
end

if dir "$source"
    capture current pwd -s
    zip "$source" "$archive" -f
    stat "$archive"
else
    stop "Project directory is missing"
end

Riferimento dei comandi