Parte 13

Construa uma biblioteca pessoal: transforme trabalho útil em prática transferível

Neste ponto, o terminal deixa de ser uma lista de comandos. Ele vira uma coleção de métodos em que você confia: investigar este tipo de problema, transformar aquele tipo de arquivo, empacotar este projeto, verificar aquele versão publicada, reconstruir este ambiente.

Guarde métodos numa biblioteca em vez de guardá-los na memória

Crie pastas por finalidade — verificações, implantação, mídia, migração e diagnóstico — e mantenha um script curto ou nota para cada rotina comprovada. Os nomes devem explicar quando você procuraria aquela ferramenta daqui a seis meses.

Uma pasta privada copiada entre projetos já funciona como um ambiente pessoal portátil. Ela preserva anos de pequenas decisões que, de outra forma, precisariam ser redescobertas.

cd lil-playground

md library

md library/checks

md library/deploy

md library/media

Prefira receitas pequenas que possam ser combinadas

Uma boa rotina responde uma pergunta ou faz uma transformação limitada. hosting-baseline.lil, package-project.lil e network-check.lil são mais fáceis de confiar do que um script enorme que edita configuração, envia arquivos, muda permissões e toca no banco de uma vez.

Composição mantém o risco visível. Um arquivo linear #lil pode chamar comandos comuns; um fluxo de trabalho run pode chamar fluxos de trabalho filhos quando decisões forem necessárias. Deixe nomes, entradas esperadas e saídas óbvias.

Registre a diferença, não apenas o arquivo final

diff transforma dois estados de texto numa mudança revisável e pode salvar um patch. Isso costuma ser mais informativo do que uma segunda cópia chamada final-final-2.txt, porque a própria mudança fica inspecionável.

Combine registros de mudança com hash para artefatos de versão publicada. Um patch explica o que mudou; um resumo criptográfico diz se os bytes continuam idênticos depois. Nenhum substitui backup, mas juntos tornam entrega e verificação muito mais tranquilos.

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

Pequenos utilitários exatos evitam código descartável desnecessário

rand gera inteiros seguros, tokens e UUIDs; math faz cálculos e conversões validados. Eles ajudam quando um fluxo de trabalho precisa de um valor exato e escrever um script PHP temporário criaria mais superfície do que valor.

Um valor aleatório criptograficamente seguro ainda não é um sistema de gestão de segredos, e uma calculadora não é um motor de regras de negócio. Use utilitários pequenos para trabalhos pequenos e mantenha políticas importantes explícitas no fluxo de trabalho que usa o resultado.

rand -uuid

rand 1 100

math clamp 105 0 100

math round 82.456 1

Mantenha a ferramenta antes que uma emergência torne a manutenção urgente

De vez em quando execute core, doctor -q e upgrade -c quando o ambiente estiver saudável. Assim você aprende como o “normal” se parece e percebe atualizações ou dependências ausentes antes de um incidente de produção.

Manutenção é melhor quando é entediante. Mantenha o repositório confiável, revise mudanças, preserve cópias de segurança e registre as poucas decisões locais que tornam este servidor diferente de outro.

core

doctor -q

upgrade -c

Saiba resetar uma camada sem queimar o ambiente inteiro

clear redefine apenas o que você vê. Módulos podem ser desinstalados individualmente. A interface opcional pode ser redefinida separadamente. A camada de extensões pode ser removida mantendo o Core. kill completo existe, mas é o último limite, não um reflexo de solução de problemas.

Esse modelo em camadas é um bom hábito de terminal em geral: identifique o menor estado que realmente está quebrado e resete só ele. Destruição raramente substitui diagnóstico.

clear

Termine com um fluxo de trabalho cujo resultado possa ser provado

O exemplo final verifica se a área de trabalho existe, cria um TAR, testa o arquivo compactado, inspeciona o artefato e calcula um resumo criptográfico. Cada etapa estabelece uma precondição ou produz evidência para a etapa seguinte.

Execute primeiro com -n e depois com -v. Mude os nomes de raiz e arquivo compactado só depois de entender o resultado. O objetivo não é este arquivo compactado específico — é o hábito de construir procedimentos que expliquem a si mesmos.

run library/release-check.lil -n

run library/release-check.lil -v

A habilidade real é o método, não o vocabulário de comandos

Linux, macOS, Windows e ambientes de execução da hospedagem não são iguais, e o lil-terminal não finge que são. O que se transfere é a cultura: inspecionar o estado atual, fazer uma mudança limitada, verificar o resultado e então salvar a parte repetível.

Quando isso fica natural, um terminal novo deixa de ser uma parede de sintaxe desconhecida. Você tem perguntas a fazer, evidências a coletar e rotinas a adaptar. Esse é o objetivo desta introdução: não terminar o aprendizado, mas fazer a linha de comando parecer um lugar onde você consegue trabalhar.

Guarde isto como script

Salve o fluxo de trabalho final como library/release-check.lil. Ele não conhece o seu projeto de negócio: demonstra a forma reutilizável de um ponto de controle de versão publicada — verificar a área de trabalho, criar um arquivo compactado, testá-lo, inspecioná-lo e registrar um resumo criptográfico.

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