Linux / Kernel / Shell
Streams, Pipe e Redirection
Passare da comandi isolati a flussi reali: , , , e operative.
Modalità
Checkpoint 1
Distinguere , e senza confonderli.
Checkpoint 2
Usare con >, >>, 2> e 2>&1 in modo intenzionale.
Checkpoint 3
Comporre utili con grep, wc, sort e uniq.
Glossario del capitolo
Termini da tenere aperti mentre studi
Tocca un termine per aprire il drawer e collegare teoria, comandi e pratica Linux.
Sezione operativa
I tre stream: stdin, stdout, stderr
In non tutto l'output è uguale: è il risultato normale, contiene errori o diagnostica, è l'ingresso che un comando può ricevere da tastiera o da un altro comando. È questa separazione che rende possibile costruire workflow affidabili invece di one-liner confusi.
Il salto di qualità operativo arriva quando inizi a chiederti: questo comando sta producendo dati, errori, o entrambi? Da lì nasce la differenza tra debug casuale e troubleshooting ordinato.
Da tenere a mente
- e vanno trattati come canali diversi.
- è il punto di aggancio tra un comando e il successivo.
- Separare i flussi riduce diagnosi sbagliate e output sporco.
Osserva output normale
$ echo "deploy ok"deploy okProduce solo : è il caso più semplice, utile per capire cosa succede quando non ci sono errori o diagnostica separata.
Genera un errore controllato
$ ls /percorso-inesistentels: cannot access /percorso-inesistente: No such file or directoryQui il contenuto va su . È il caso base per capire perché salvare output e catturare errori non sono la stessa operazione.
Sezione operativa
Redirection e pipe in pratica
Con > sovrascrivi file, con >> appendi, con 2> separi gli errori, con 2>&1 unisci stream diversi quando ti serve un unico. Il carattere | collega del primo comando allo del secondo, cioè trasforma output grezzo in input elaborabile.
Il punto non è memorizzare simboli: è saperli usare per costruire una procedura osservabile, verificabile e riusabile.
Da tenere a mente
- > sovrascrive, >> aggiunge, 2> isola .
- 2>&1 serve quando vuoi un unico e ordinato.
- Le sono forti quando ogni step ha uno scopo leggibile.
Sequenza breve in stile runbook: prima osservi output e errori, poi li separi, poi li trasformi in informazione utile.
Salva output normale in file
Capture stdout
$ ls -la > elenco.txtReindirizza in elenco.txt. Se il file esiste viene sovrascritto.
Aggiungi contenuto senza sovrascrivere
Append risultati
$ pwd >> elenco.txtCon >> appendi al file esistente senza perdere il contenuto precedente.
Separa gli errori in un file dedicato
Capture stderr
$ ls /cartella-che-non-esiste 2> errori.txtL'errore non va a schermo: finisce in errori.txt perché è stream .
Filtra e conta con una pipeline
Pipeline leggibile
$ cat /etc/passwd | grep bash | wc -l3Prima filtri le righe, poi le conti. Tre comandi semplici collegati da .
Consolida output ed errori in un log unico quando serve
Unify streams
$ find /etc -maxdepth 1 -name "*.conf" > report.txt 2>&1Quando vuoi un solo artefatto da condividere o allegare a un ticket, unisci e nello stesso file in modo esplicito.
Sezione operativa
Pattern di workflow da riusare
Quando una è chiara e ripetibile, hai già un runbook in miniatura. Non serve partire da script complessi: serve prima una procedura manuale che puoi spiegare a voce e verificare passo dopo passo.
La regola pratica è sempre la stessa: osserva output grezzo, isola errori, filtra il rumore, salva solo ciò che serve davvero.
Da tenere a mente
- Osserva -> filtra -> salva: sequenza base affidabile.
- corte e leggibili battono one-liner opachi.
- Separare errori riduce diagnosi sbagliate.
Conta gli shell user interattivi
$ grep bash /etc/passwd | cut -d: -f1 | sortmike
rootEsempio semplice di con scopo chiaro: filtrare, estrarre un campo, ordinare il risultato finale.
Checkpoint finale
Cosa portarti via
- Gli stream sono il fondamento dei workflow shell moderni.
- Pipe e redirection permettono composizione invece di comandi isolati.
- Separare stdout/stderr rende debug e automazione molto più robusti.
Prompt operativo
Fermati e ragiona
- Quando conviene separare stderr in un file e quando no?
- Perché una pipeline leggibile è spesso meglio di un comando monolitico?
Progress Dashboard Quiz
Hai completato 0/0 domande su 16 capitoli con quiz.
Capitoli completati: 0/16
Quiz capitolo
Verifica rapida
Stai costruendo un log incrementale di diagnostica. Quale operatore evita di perdere il contenuto precedente?
Navigazione
Capitolo 12 di 16