Portes tres lliçons escrivint 2>/dev/null, | i > sense que ningú t'hagi explicat del tot què són. Els has copiat perquè funcionen. Aquesta lliçó desmunta la mecànica, i és probablement la més important del mòdul: la redirecció i les canonades són el mecanisme amb què la filosofia Unix del Mòdul 1 —programes petits que fan una cosa bé i es componen— passa de ser una frase bonica a ser una cosa que es tecleja.

No és un tema on n'hi hagi prou de memoritzar símbols. Hi ha un grapat de casos —2>&1 >fitxer enfront de >fitxer 2>&1, el codi de sortida d'una canonada, sudo echo x > /etc/...— en què la intuïció enganya i tothom s'equivoca almenys una vegada. Hi anem amb el detall suficient perquè no et passi.

1. Els tres fluxos estàndard i per què existeixen
2. Veure'ls de debò a /proc
3. Redirecció de sortida
4. Redirecció d'entrada
5. Redirecció d'error i l'ordre d'avaluació
6. Els fitxers especials de /dev
7. Here-documents i here-strings
8. Canonades: què són realment
9. El codi de sortida d'una canonada
10. tee i el patró | sudo tee
11. Memòria intermèdia: quan la sortida no apareix
12. Compondre una canonada pas a pas

Tot procés a Linux neix amb tres canals ja oberts. No són una convenció de Bash: els obre el sistema i estan identificats per un número, el descriptor de fitxer.

La pregunta interessant és per què hi ha dos canals de sortida si tots dos van a la pantalla. La resposta és la clau de tot el disseny: per poder separar-los quan cal. Si el resultat i els errors viatgessin pel mateix canal, no podries guardar en un fitxer només el que és útil, ni encadenar un programa amb un altre sense que els avisos contaminessin les dades.

> va redirigir només stdout al fitxer. L'error es va quedar a la pantalla perquè viatja per stderr. Aquesta separació és deliberada i és el que permet que un find que recorre /etc amb avisos de permís denegat continuï produint una llista neta.

Com que tot és un fitxer, els descriptors es poden mirar:

Els tres apunten a /dev/pts/0, el teu pseudoterminal. El 255 és d'ús intern de Bash. Ara fixa't en què passa dins d'una redirecció:

Els descriptors 1 i 2 ja no apunten al terminal, sinó al fitxer. Redirigir no és una funció de l'ordre: és una cosa que Bash fa al procés fill abans d'arrencar-lo. Per això funciona amb qualsevol programa, sense que el programa hagi de saber res.

> trunca el fitxer abans d'executar l'ordre, i el crea si no existeix. Això significa que un > sobre un fitxer amb dades les destrueix encara que l'ordre falli després.

noclobber converteix > en una operació que falla si el destí existeix, i deixa >| com la forma explícita de dir «sí, sobreescriu». És un bon ajust per a una sessió de treball en producció; consulta'l amb set -o | grep noclobber i desactiva'l amb set +o noclobber. La convenció del curs —còpia .bak-$(date +%F) abans de tocar res— i noclobber es reforcen mútuament.

< fitxer connecta stdin al fitxer. Moltes ordres accepten el nom del fitxer com a argument, així que la diferència sembla cosmètica. No ho és:

Amb <, el programa no coneix el nom del fitxer: només rep un flux de bytes, i per això no l'imprimeix. És el que vols quan el número ha d'alimentar un altre càlcul. (26 línies: la capçalera més els 25 registres.)

Aquí hi ha el punt on tothom s'equivoca. Bash processa les redireccions d'esquerra a dreta, i 2>&1 no significa «uneix els dos fluxos per sempre»: significa «copia el destí actual d'1 sobre 2». És una fotografia de l'estat en aquell instant.

Pas a pas: > /tmp/ok.txt apunta 1 al fitxer; després 2>&1 copia aquest destí sobre 2. Tots dos acaben al fitxer. Correcte.

Pas a pas: 2>&1 copia el destí actual d'1, que encara és el terminal, sobre 2; després > /tmp/mal.txt mou 1 al fitxer, però 2 s'ha quedat apuntant al terminal. Resultat: l'error surt per pantalla i només la sortida normal va al fitxer. És exactament el contrari del que la majoria es pensa que està escrivint.

La regla pràctica: 2>&1 va sempre al final. I si no necessites compatibilitat amb altres shells, &> fitxer és inequívoc i no admet l'error.

Hi ha un ús legítim de l'ordre «equivocat»: ordre 2>&1 >/dev/null | grep alguna-cosa envia només els errors a la canonada i descarta la sortida normal. És estrany, però quan el necessites és l'única manera.

2>/dev/null és el silenciador de soroll que ja feies servir a 03-03. Fes-lo servir amb criteri: descarta tots els errors, inclosos els que sí que volies veure. Si només vols ignorar els de permís denegat, millor filtrar que silenciar a cegues.

/dev/stdout com a ruta resulta útil quan una ordre exigeix un nom de fitxer i tu en vols la sortida a la canonada, com ara tar -cf /dev/stdout. I /dev/zero serveix per generar un fitxer de mida coneguda amb què provar una còpia de seguretat:

Un here-document alimenta stdin amb text escrit a la mateixa línia d'ordres, fins a un delimitador.

Amb el delimitador entre cometes simples no s'expandeix res:

La regla: posa el delimitador entre cometes tret que vulguis expansió deliberadament. És el mateix que la regla de les cometes de 03-01, aplicada a blocs.

Un here-string <<< és la versió d'una sola línia, i evita l'echo ... | que s'escriu per costum:

Una canonada no és un fitxer temporal. És una memòria intermèdia del nucli —típicament 64 KiB— amb dos extrems: la sortida estàndard del procés de l'esquerra i l'entrada estàndard del de la dreta.

I aquí hi ha el punt que cal entendre: els dos processos s'executen alhora, no l'un després de l'altre. El de la dreta comença a consumir tan bon punt hi ha dades. Si la memòria intermèdia s'omple perquè el consumidor va més lent, el nucli adorm el productor fins que hi hagi lloc; si es buida, adorm el consumidor. Aquesta sincronització automàtica és la raó que puguis fer cat fitxer-de-50-GB | grep alguna-cosa sense esgotar la memòria.

Dos processos simultanis. grep escriu a la memòria intermèdia, wc en llegeix, i cap dels dos no sap que l'altre existeix: un es pensa que escriu a la pantalla i l'altre es pensa que llegeix del teclat. Això és exactament el que fa possible compondre programes que mai no van ser dissenyats per treballar junts.

La canonada només transporta stdout. Els errors de l'ordre de l'esquerra continuen anant a la pantalla. Per ficar-los també a la canonada, |& (equivalent a 2>&1 |):

Per defecte, $? retorna el codi de l'última ordre de la canonada. Les anteriors es perden, i això amaga fallades:

cat va fallar, però wc va acabar bé i la canonada informa d'èxit. Un procediment que comprovi $? donaria per bona una operació que no va llegir res.

La matriu PIPESTATUS guarda el codi de cada element:

I set -o pipefail fa que la canonada retorni el codi de l'última ordre que va fallar:

pipefail és imprescindible en scripts seriosos i el veuràs integrat a set -euo pipefail al Mòdul 4. Aquí queda't amb la idea: una canonada et pot mentir sobre el seu èxit, i saps dues maneres que no ho faci.

tee llegeix de stdin i escriu alhora a stdout i a un o més fitxers. Bifurca el flux.

Veus el recompte i a més conserves les línies en un fitxer. Amb -a afegeix en comptes de truncar, i amb - com a destí addicional pot duplicar a la pantalla enmig d'una canonada, cosa que la converteix en una excel·lent eina de depuració.

Sembla contradictori: hi hem escrit sudo. L'explicació és al repartiment de tasques. La redirecció l'executa Bash, no sudo. Bash obre el fitxer de destí abans de llançar res, i ho fa amb els privilegis d'operador, que no pot escriure en un fitxer de root. El sudo afecta l'echo, que és justament la part que no necessitava privilegis.

La solució és fer que el procés privilegiat sigui el que escriu:

Ara tee corre sota sudo i és ell qui obre el fitxer. El > /dev/null final descarta la còpia que tee envia a la pantalla, que aquí no aporta res. I per afegir al final, | sudo tee -a, mai >>, pel mateix motiu. Aplicat amb la convenció del curs:

El diff revela una cosa important: hem afegit una segona clau log_nivell en comptes de corregir l'existent. El fitxer ara en té dues, i quina guanya depèn de com el llegeixi l'aplicació. Aquest és el motiu pel qual la convenció exigeix el diff -u: no per admirar el canvi, sinó per descobrir que no era el que volies. La correcció al lloc és feina de sed, a la lliçó següent.

Un programa escriu en una memòria intermèdia i només l'aboca quan s'omple o quan acaba. La biblioteca de C aplica una regla que sorprèn: si stdout és un terminal, la memòria intermèdia és per línies; si és una canonada o un fitxer, és per blocs de 4 KiB.

Conseqüència pràctica: tail -F acces.log | grep 'ERROR 500' pot no mostrar res durant minuts, no perquè no hi hagi errors, sinó perquè grep està acumulant 4 KiB abans de deixar-los anar. Sembla que la canonada està trencada i funciona perfectament.

stdbuf -oL força la memòria intermèdia per línies de l'ordre següent. Alternatives: grep --line-buffered, awk amb fflush(), sed -u. Recorda que la convenció del curs és tail -F i mai -f en producció, perquè -F sobreviu a la rotació del fitxer.

L'objectiu: les rutes amb més errors 500 a acces.log. Es construeix per increments, verificant cada baula, igual que feies amb les expressions regulars.

De 412 línies en queden 14. Ara n'extraiem només la ruta i agrupem:

Nou de catorze a /reserves, i els ms=30012 de la mostra freguen els 30 segons, que és exactament el timeout_consulta=30 d'app.conf. La canonada no ha donat una dada: ha donat una hipòtesi —les consultes a la base de dades esgoten el temps límit— que encaixa amb el connexions_actives=200 que vam veure a 03-03 i amb el max_connexions=200 configurat. Això és el que se li porta a la Marta.

Repassa la composició: grep filtra, grep -oE extreu, sort agrupa el que és igual, uniq -c compta, sort -rn ordena per freqüència. Cinc programes que no es coneixen entre si, encadenats per una memòria intermèdia del nucli. Cap no sap fer l'informe; junts, sí.

• Escriure 2>&1 abans de la redirecció de sortida. És l'error clàssic. Va al final, o fes servir &>.
• ordre > fitxer amb el mateix fitxer com a entrada. sort dades.txt > dades.txt el buida: Bash trunca el destí abans que sort llegeixi. Fes servir sort -o dades.txt dades.txt o un temporal.
• sudo ordre > /fitxer/protegit. La redirecció la fa el teu shell. Fes servir | sudo tee.
• Fiar-se de $? després d'una canonada. És el de l'última ordre. Fes servir PIPESTATUS o pipefail.
• Silenciar amb 2>/dev/null per reflex. Estàs descartant també els errors que necessitaves. Mira-te'ls primer.
• Creure que una canonada és seqüencial. Els processos corren alhora; per això funciona amb fitxers enormes i per això la memòria intermèdia pot endarrerir la sortida.
• Oblidar posar entre cometes el delimitador d'un here-doc. Si el text conté $ o cometes, s'expandirà.
• Consell: intercala | tee /tmp/pas1.txt | enmig d'una canonada llarga per inspeccionar què hi circula per aquell punt sense trencar la cadena.
• Consell: ordre | cat desactiva la sortida en color i en columnes de molts programes, perquè detecten que no escriuen a un terminal. Si et falta el color, --color=always el força.

Exercici 1. Executa un find sobre /etc com a usuari normal, de manera que la llista de resultats quedi a /tmp/troballes.txt i els errors de permís a /tmp/fallades.txt, sense que res surti per pantalla. Després compta quants errors hi va haver i explica per què no els hauries pogut separar amb &>.

Exercici 2. Afegeix la línia # revisat 2026-08-18 al final de /etc/tramontana/app.conf conservant la convenció de còpia prèvia i verificació posterior. Explica per què sudo echo ... >> no serveix.

Exercici 3. Construeix pas a pas una canonada que mostri les cinc adreces IP amb més peticions a acces.log, guardant alhora el llistat complet a /tmp/ips.txt. Verifica que el total de peticions comptades coincideix amb les 412 línies del fitxer i explica què faries si no coincidís.

Solució 1.

Dues redireccions independents, cada flux al seu fitxer, i la pantalla queda neta. &> no serveix perquè barreja tots dos fluxos en un únic destí, que és justament el contrari del que demanava l'enunciat. Els sis errors són directoris com /etc/ssl/private, legítimament tancats a un usuari normal: revisar-los al seu propi fitxer és millor pràctica que descartar-los amb 2>/dev/null, perquè un error inesperat allà dins seria un senyal que no voldries perdre.

Solució 2.

sudo echo '...' >> /etc/tramontana/app.conf falla perquè la redirecció l'executa el teu shell abans d'invocar sudo, i el teu shell corre com a operador, que no té permís d'escriptura sobre un fitxer 640 propietat de root. El sudo s'aplicaria a l'echo, que no necessita cap privilegi per imprimir text. Amb | sudo tee -a, el procés que obre el fitxer és tee, i aquest sí que corre com a root. El cp -p conserva permisos i propietari a la còpia, i ls -l confirma que l'original continua sent 640 root:tramontana: escriure amb tee sota sudo no ha canviat la propietat del fitxer, perquè tee escriu al fitxer existent en comptes de crear-lo de nou.

Solució 3.

La primera ordre és la verificació imprescindible: 412 coincidències per a 412 línies, per tant tota línia té exactament un camp ip=. Si n'haguessin sortit menys, hi hauria línies amb un altre format que s'estarien quedant fora de l'informe en silenci; si més, alguna línia amb dues IP i un recompte inflat. En tots dos casos caldria examinar les línies discordants amb grep -vc 'ip=' abans de continuar, perquè un informe construït sobre un supòsit no verificat és un informe que es pot desmentir.

tee bifurca: el fitxer rep el llistat complet i head -5 es queda amb el podi. La suma final amb awk —que estudiaràs a la lliçó següent— tanca el cercle: 412 un altre cop, així que cap petició no s'ha perdut ni duplicat pel camí. I hi ha una troballa: 10.0.2.77 concentra 138 peticions, un terç del total i gairebé el 50 % més que la següent. Mereix investigació.

Has passat de copiar símbols a entendre per on circula cada byte.

• Coneixes els tres fluxos estàndard —stdin 0, stdout 1, stderr 2—, saps per què existeixen dos canals de sortida, i els has vist de debò a /proc/<pid>/fd.
• Maneges >, >>, noclobber amb >|, i <, sabent que amb < el programa no coneix el nom del fitxer.
• Tens resolt l'error clàssic: 2>&1 copia el destí actual d'1, s'avalua d'esquerra a dreta i per això va al final; &> és la drecera inequívoca.
• Fas servir /dev/null, /dev/zero i /dev/stdout amb criteri, sabent que silenciar errors a cegues amaga els que sí que importaven.
• Escrius here-documents i here-strings, i poses el delimitador entre cometes quan no vols expansió.
• Saps que una canonada és una memòria intermèdia del nucli entre dos processos que corren alhora, que només transporta stdout, i que |& inclou els errors.
• No et fies del codi de sortida d'una canonada: coneixes PIPESTATUS i set -o pipefail.
• Apliques | sudo tee per escriure en fitxers protegits, i saps explicar per què sudo echo x > /etc/... falla: la redirecció la fa el teu shell, no sudo.
• Reconeixes la memòria intermèdia per blocs quan un registre no apareix en temps real i ho corregeixes amb stdbuf -oL.
• I has compost una canonada incrementalment fins a convertir 412 línies de registre en una hipòtesi de diagnòstic defensable.

En aquestes canonades han aparegut sort, uniq -c i fins i tot un awk sense explicar. És el deute que salda la lliçó següent. Processament de Text: cut, sort, uniq, sed i awk tanca el cercle que va obrir la filosofia Unix del Mòdul 1: el text pla com a interfície universal entre programes. Aprendràs a retallar camps, ordenar per la columna que vulguis, comptar aparicions, transformar amb sed sense destrossar l'original, i agrupar i sumar amb awk fins a substituir mitja canonada per una sola ordre. En acabar-la podràs lliurar a la Marta l'informe de facturació mensual de reserves.csv i el rànquing de rutes amb errors d'acces.log sense escriure ni una línia de codi.