Tens la instantània feta i la sessió oberta a srv-tramontana. Al davant hi tens un prompt que parpelleja i poca cosa més. Aquesta pantalla, que a primer cop d'ull sembla una limitació, és en realitat la interfície més potent que té el sistema: tot el que es pot fer en un servidor Linux es pot fer des d'aquí, i gairebé res del que es fa aquí és irrepetible.

Aquesta lliçó no és un llistat d'ordres. És la lliçó on aprens com funciona l'intèrpret que hi ha entre els teus dits i el nucli: com llegeix el que escrius, com decideix quin programa executar, com pots escriure tres vegades més ràpid fent servir bé el teclat, i com encadenar ordres perquè una depengui del resultat de l'anterior. A partir d'aquí, cada ordre nova que aprenguis es recolzarà en aquesta mecànica.

En acabar hauries de poder seure davant de qualsevol terminal Linux i moure't sense fricció: sense esborrar una línia sencera a base de retrocés, sense tornar a teclejar una ordre que ja vas executar fa deu minuts, i sense que un espai en un nom de fitxer t'espatlli l'ordre.

1. Per què la línia d'ordres continua sent l'eina professional
2. El cicle REPL: què fa el shell amb el que escrius
3. Anatomia d'una ordre: ordre, opcions i arguments
4. Ordres internes i externes: builtins, type, which i command -v
5. Com troba el shell un executable
6. Autocompletat amb Tab
7. L'historial d'ordres
8. Editar la línia d'ordres sense patir
9. Encadenar ordres: ;, &&, || i agrupació
10. Executar en segon pla amb &
11. Cometes i escapament: quan el nom té espais
12. Cancel·lar i sortir

La pregunta és legítima: el 2026, amb interfícies gràfiques madures i panells web d'administració, per què un professional treballa en un terminal?

La resposta no és nostàlgia. Són quatre propietats que la interfície gràfica no pot oferir:

• Reproductibilitat. Una ordre és text. Es copia, s'enganxa, es desa en un document, es revisa en una revisió de codi i s'executa idèntica d'aquí a sis mesos. «Fes clic a Configuració, després a la pestanya Avançat, després marca la tercera casella» no és reproduïble: depèn de la versió, de l'idioma i que la casella hi continuï sent.
• Automatització. El que escrius a mà avui és literalment la primera línia de l'script que ho farà sol demà. Entre executar una ordre i automatitzar-la no hi ha traducció: és el mateix text. En una interfície gràfica, automatitzar vol dir reescriure tot el procés en un altre llenguatge.
• Treball remot. srv-tramontana no té monitor ni el tindrà. Quan el servidor sigui en un centre de dades o al núvol, la teva única porta serà SSH. La CLI està dissenyada per a això; l'escriptori remot és un pedaç.
• Cost en recursos i amplada de banda. Una sessió SSH consumeix uns pocs kilobytes per minut i funciona sobre una connexió mòbil dolenta des d'un tren. Un escriptori remot necessita megabits i cau. Quan tinguis una incidència a les tres de la matinada des del mòbil, això deixarà de ser un detall tècnic.

Ara la part honesta, perquè la CLI no guanya en tot:

Aquest últim punt mereix que t'hi aturis. La filosofia Unix que vas veure al Mòdul 1 inclou una regla implícita: el silenci és senyal d'èxit. Si una ordre funciona, normalment no diu res. I si li demanes que esborri un arbre de directoris, l'esborra sense preguntar. La potència i el perill són la mateixa propietat vista des de dos costats.

La conclusió professional no és «la CLI és millor», sinó: per administrar sistemes, la CLI és l'eina correcta, i no dominar-la et limita a fer a mà el que altres automatitzen.

Bash no executa el que escrius. Executa el resultat de processar el que escrius. Entendre aquesta diferència t'estalviarà moltes sorpreses.

El shell funciona en un bucle anomenat REPL (Read–Eval–Print–Loop): llegeix, avalua, mostra i torna a començar.

Fixa't en el pas EXPANDIR: passa abans d'executar res. Quan escrius una ordre amb un *, el programa no veu mai l'asterisc; veu la llista de noms que el shell ha posat al seu lloc. Els comodins i les variables s'estudien al Mòdul 3, però convé que sàpigues ja que existeix aquesta fase intermèdia, perquè explica comportaments que d'altra manera semblen màgics.

I fixa't en TROSSEJAR: el shell divideix la línia per espais abans de saber què signifiquen. Aquest detall és la causa del problema de les cometes que veuràs a l'apartat 11.

Ja vas veure la forma general al Mòdul 1. Ara la desmuntem sencera:

• Ordre: què vols fer. Sempre la primera paraula.
• Opcions (o flags, modificadors): com ho vols fer. Comencen per - o --.
• Arguments (o operands): sobre què ho vols fer. Normalment fitxers o rutes.

Aquí ls és l'ordre, -l i -h són opcions i /var/log/tramontana és l'argument. Sense argument, ls fa servir un valor per defecte (el directori actual); sense opcions, fa servir el seu comportament per defecte.

Les tres invocacions següents són equivalents:

Criteri professional: fes servir curtes quan escrius a mà (rapidesa) i llargues quan escrius un script o documentes un procediment (llegibilitat). D'aquí a sis mesos, --human-readable s'entén sol; -h t'obliga a mirar el manual. I compte: -h no significa el mateix a totes les ordres.

-- tot sol significa «s'han acabat les opcions; tot el que vingui després és un argument, encara que comenci per guionet».

Sense --, rm interpreta -informe.txt com un munt d'opcions soltes. És un cas rar escrivint a mà, però deixa de ser-ho quan un script rep noms de fitxer de fora: qualsevol nom que comenci per guionet pot alterar el comportament de l'ordre. Per això els scripts seriosos (Mòdul 4) fan servir -- abans de les dades.

No totes les ordres són programes. Hi ha dues categories:

• Builtins (internes): les implementa Bash. No hi ha cap fitxer per executar; el shell fa la feina ell mateix. Són rapidíssimes.
• Externes: són executables al disc (/bin/ls, /usr/bin/find...). El shell crea un procés nou per executar-les.

L'eina per distingir-les és type:

type -a mostra totes les resolucions possibles, en ordre de prioritat. És l'eina de diagnòstic quan una ordre «no fa el que hauria de fer»: gairebé sempre hi ha un àlies o un script per davant del programa real.

which cd no retorna res i falla, perquè cd no és un fitxer. Aquesta és exactament la limitació per la qual which no serveix com a eina de diagnòstic general.

Aquesta pregunta apareix a les entrevistes tècniques, i la seva resposta explica alguna cosa real sobre com funciona el sistema.

Cada procés a Linux té el seu propi directori de treball, que és un atribut privat del procés. Quan executes un programa extern, el shell crea un procés fill i aquest fill hereta una còpia de l'entorn del pare. El fill pot canviar el que vulgui de la seva còpia: quan acaba, la seva còpia desapareix i el pare continua exactament igual.

Si cd fos un programa extern, canviaria el directori del seu propi procés i moriria immediatament. El teu shell no es mouria mai. Per això cd ha d'executar-se dins del procés mateix del shell, és a dir, ser un builtin.

La mateixa lògica s'aplica a export, alias, source, exit, umask o history: tot el que modifica l'estat del shell ha de ser intern. Guarda't aquesta idea, perquè és la que explica per què un script no pot canviar el directori de qui el crida (Mòdul 4).

Quan escrius grep, el shell no rastreja el disc. Segueix un ordre estricte:

1. És un àlies? El substitueix.
2. És una funció de shell? L'executa.
3. És un builtin? L'executa.
4. Si no, busca un fitxer executable amb aquest nom als directoris llistats a la variable PATH, en ordre, i fa servir el primer que troba.
5. Si no el troba: command not found.

Són directoris separats per :. És una llista de llocs on mirar, no una cerca per tot el disc. Dues conseqüències pràctiques:

• Un programa que és en un directori fora del PATH no s'executa escrivint-ne el nom. Cal donar-ne la ruta: per això els teus scripts a /home/operador/scripts es llançaran com a ./informe.sh o amb la ruta completa.
• L'ordre importa. Si hi hagués dos executables amb el mateix nom en dos directoris del PATH, guanya el que aparegui abans.

El directori actual no és al PATH, i això és una decisió de seguretat deliberada: si hi fos, deixar un fitxer anomenat ls en un directori compartit n'hi hauria prou per enganyar qui hi entrés. No afegeixis mai . al PATH.

El detall complet de PATH (com es modifica, on es defineix i què és exactament una variable d'entorn) és matèria de la lliçó 03-01. Aquí en tens prou amb el concepte.

El tabulador és la tecla que més millorarà la teva velocitat, i no només per estalviar pulsacions: completar amb Tab evita errades. Si el nom es completa sol, existeix.

Regles de funcionament:

• Una pulsació amb una única coincidència: completa la resta.
• Una pulsació amb diverses coincidències: completa la part comuna i s'hi queda (i sol emetre un xiulet).
• Dues pulsacions: mostra la llista de totes les coincidències.

Què completa segons la posició a la línia:

Aquesta última fila depèn del paquet bash-completion, present per defecte a Ubuntu Server 24.04. Gràcies a ell, moltes ordres completen les seves pròpies opcions i fins i tot els seus arguments:

Consell d'higiene: si escrius un nom llarg sencer i sense Tab, i després falla, has perdut el temps dues vegades. Escriu tres lletres i prem Tab. Si no completa, és que el fitxer no és on creus, i acabes de descobrir l'error abans d'executar res.

Bash desa el que executes a memòria durant la sessió i ho aboca al fitxer ~/.bash_history en sortir. Això et permet no reescriure mai el mateix dues vegades.

Formes de reaprofitar l'historial:

Ctrl+R és, de bon tros, la drecera més rendible de l'apartat. Prem Ctrl+R, escriu tram i Bash et va mostrant l'ordre més recent que contingui aquesta cadena. Prem Enter per executar-la o fletxa dreta per editar-la abans.

Els dos modismes més útils del dia a dia són !! i !$:

sudo !! reexecuta l'ordre anterior amb privilegis. Bash mostra la línia expandida abans d'executar-la, cosa que et dona l'oportunitat de veure què passarà.

!$ recupera l'últim argument: patró clàssic de «primer miro, després actuo» sense tornar a escriure la ruta.

Un advertiment de seguretat que convé interioritzar ja: l'historial és un fitxer de text pla. Si escrius una contrasenya com a argument d'una ordre, queda desada a ~/.bash_history. No passis mai secrets per la línia d'ordres; la gestió correcta de credencials es tracta a la lliçó 06-05.

Bash fa servir la biblioteca readline, que porta les dreceres d'edició de l'editor Emacs. Les mateixes dreceres funcionen en molts altres programes de terminal, així que aprendre-les rendeix més enllà del shell.

Regla mnemotècnica: A d'anfang o «principi de l'abecedari», E d'end, K de kill fins al final, U d'undo fins al principi, W de word.

El cas pràctic més freqüent: escrius una ordre llarga, veus una errada al principi i ets al final. En comptes de mantenir premut el retrocés, Ctrl+A, corregeixes, Ctrl+E, Enter. I si la línia sencera està malament: Ctrl+U l'esborra de cop.

Detall útil: en molts emuladors de terminal, Alt funciona directament; si no, l'alternativa és prémer Esc i deixar-lo anar abans de la lletra (Esc i després B equival a Alt+B).

Pots posar diverses ordres en una sola línia, i la diferència entre els separadors no és cosmètica: és lògica de control.

Per entendre-la necessites el codi de sortida: tota ordre, en acabar, retorna un número. 0 significa èxit; qualsevol altre valor significa fallada. El consultes amb $? (ho desenvoluparem a la lliçó 02-02).

La diferència és crítica a la pràctica. Compara aquestes dues línies:

Si el directori no existeix, la primera canvia d'opinió però no d'intenció: no hi entra, i esborra antics al directori on fossis, que pot ser el teu home. La segona no fa res. Regla que has d'adoptar des d'avui: quan una ordre depengui que l'anterior hagi funcionat, fes servir &&, mai ;.

Es poden combinar els tres, i també agrupar amb parèntesis:

Els parèntesis agrupen ordres en un subshell: un procés fill amb el seu propi directori de treball i el seu propi estat.

El cd de dins dels parèntesis va afectar només el subshell; en tornar, continues on eres. És exactament el mecanisme de l'apartat 4, ara fet servir a favor teu: entra, fes alguna cosa, i que el cd no et contamini la sessió.

Amb claus { ...; } s'agrupa sense crear subshell (els canvis sí que afecten la teva sessió). És una distinció que reprendrem en escriure scripts al Mòdul 4.

Un & al final d'una ordre la llança en segon pla: el shell no espera que acabi i et retorna el prompt immediatament.

• [1] és el número de treball dins d'aquesta sessió; 4127 és el PID del procés al sistema.
• jobs llista els treballs de la sessió, fg en porta un al primer pla i bg reprèn en segon pla un de detingut.
• Ctrl+Z atura (no mata) el procés en primer pla i et retorna el prompt.

Aquestes són només les nocions perquè reconeguis la sintaxi. El control de treballs complet, els processos, els senyals i què passa amb un procés en segon pla quan tanques la sessió són matèria de la lliçó 03-06.

Torna al cicle REPL de l'apartat 2: el shell trosseja la línia per espais abans d'executar res. Aquí hi ha l'explicació d'un error clàssic:

rm no va veure mai un nom amb espai: va rebre dos arguments, informe i agost.txt. El shell va fer la seva feina; el problema és que no li vas dir que l'espai formava part del nom.

Tres maneres d'arreglar-ho:

I la quarta, la que faràs servir de debò: escriu inf i prem Tab. Bash completa el nom i n'escapa l'espai per tu.

Diferència entre els tres mecanismes:

La regla pràctica fins al Mòdul 3 és senzilla: si vols el text tal qual, cometes simples; si esperes que alguna cosa de dins se substitueixi, cometes dobles. Per què se substitueix i què més es pot substituir és el contingut de la lliçó 03-01.

Un apunt d'estil aplicable a srv-tramontana: no posis espais als noms de fitxer d'un servidor. Fes servir guionets o guions baixos (informe-agost.txt). No és una mania: cada espai és un parany esperant que algú escrigui un script sense cometes.

Tres tecles que cal distingir bé perquè es confonen sovint:

La diferència entre Ctrl+C i Ctrl+D importa: Ctrl+C interromp, Ctrl+D diu que no hi ha més dades. Si una ordre sembla penjada sense fer res, moltes vegades està esperant que escriguis alguna cosa pel teclat i la sortida correcta és Ctrl+D, no Ctrl+C.

I Ctrl+Z no mata res, només ho suspèn. És un error freqüent creure que has tancat un editor amb Ctrl+Z quan en realitat l'has deixat aturat en segon pla, bloquejant el fitxer.

Fer servir ; on tocava &&. És l'error d'aquest capítol amb conseqüències més greus, perquè només es manifesta quan alguna cosa falla, és a dir, en el pitjor moment. Encadena amb && per defecte.

Escriure rutes llargues a mà. Cada caràcter teclejat és una oportunitat d'errada. Tab sempre.

Confiar en which per diagnosticar. No veu builtins ni àlies. Si alguna cosa es comporta estranyament, type -a és la resposta.

Oblidar que Linux distingeix majúscules. Reserves.csv i reserves.csv són dos fitxers diferents. Venint de Windows, això mossega durant les primeres setmanes.

Espais sense protegir. Si un nom té espais i no el poses entre cometes, el shell veurà diversos arguments. I si l'ordre era rm, esborrarà coses que no volies.

Copiar ordres d'internet sense llegir-les. Especialment les que comencen per sudo o contenen rm -rf. Abans d'executar alguna cosa que no entens, llegeix-la sencera i, si cal, consulta-la al manual (lliçó 02-02).

Consell: escriu primer l'ordre inofensiva. Vas a esborrar amb un patró? Executa abans ls amb el mateix patró i mira què surt. Després prem fletxa amunt, canvia ls per rm i executa. És el costum que separa qui ha perdut dades de qui no.

Consell: parteix una línia llarga en diverses. Una barra invertida al final de la línia permet continuar a la següent, i fa les ordres complexes molt més llegibles quan les enganxes a la documentació.

Consell: Ctrl+L en comptes de clear. És més ràpid i no perds la línia que estiguessis escrivint.

A srv-tramontana, respon amb ordres (no de memòria):

1. echo és un builtin, un programa extern, o totes dues coses?
2. Quants directoris hi ha al teu PATH?
3. Té ls algun àlies definit? Quin?
4. Per què which cd no retorna res?

En Luis Ferrer et passa per xat aquesta línia per netejar els bolcats temporals de l'aplicació, dient que «l'ha provada al seu portàtil i va bé»:

Explica què pot sortir malament, reescriu-la de manera segura i afegeix-hi una comprovació prèvia que t'ensenyi què s'esborrarà abans d'esborrar-ho.

Sense fer servir el ratolí i sense esborrar caràcter a caràcter:

1. Escriu ls -l /var/log/tramontana/acces.log i executa-ho.
2. Executa ara wc -l sobre aquest mateix fitxer sense tornar a teclejar la ruta.
3. Recupera de l'historial la primera ordre i modifica-la perquè mostri errors.log en comptes d'acces.log, fent servir només dreceres d'edició.
4. Crea un fitxer anomenat informe marta.txt, comprova que existeix i esborra'l. Explica per què el nom és una mala idea en un servidor.

Solució 1

Totes dues coses. Bash té el seu propi echo builtin i a més existeix /usr/bin/echo. Guanya el builtin, perquè els interns tenen prioritat sobre el PATH. És un cas freqüent: echo, test, kill o printf existeixen en les dues formes, i les seves opcions no sempre coincideixen entre elles, cosa que explica alguns comportaments desconcertants en scripts portats d'un sistema a un altre.

Sis directoris, separats per :. Els pots comptar a ull; al Mòdul 3 veuràs com fer-ho amb una ordre.

Sí: Ubuntu defineix ls --color=auto al ~/.bashrc. Per això els directoris et surten en blau: no és ls fent-ho pel seu compte, és l'àlies. Els àlies s'estudien a 03-01.

which cd no retorna res perquè cd no és un fitxer al disc: és un builtin. I ha de ser-ho perquè ha de canviar el directori de treball del procés mateix del shell, cosa que un procés fill no pot fer sobre el seu pare.

Solució 2

Què pot sortir malament. El punt i coma executa rm -r * passi el que passi amb el cd. Si /srv/tramontana/backups/temporals no existeix, està mal escrit, o el directori ha estat reanomenat, cd falla i rm -r * s'executa al directori actual. Si en aquell moment eres a /home/operador, acabes d'esborrar el teu home, inclòs /home/operador/scripts. Si eres a /opt/tramontana, t'has emportat l'aplicació per davant.

Que «funcioni al portàtil d'en Luis» és precisament el senyal d'alarma: funciona mentre el directori existeixi. La fallada apareix el dia que no existeix, que és el dia que ningú no mira.

Versió segura:

Millores aplicades:

• && en comptes de ;: si el cd falla, no s'esborra res. És el canvi important.
• ls -la primer: veus exactament què hi ha abans de destruir-ho.
• ./* en comptes de *: protegeix davant de noms que comencin per guionet.
• -I: demana una confirmació única quan hi ha més de tres elements. Menys molest que -i i suficient per aturar-te a pensar.

Alternativa encara millor, que evita el cd del tot i no deixa la sessió en un altre directori:

Com l'hi diries a en Luis: no que la seva ordre estigui mal escrita, sinó que li falta la condició. El ; diu «fes això i després allò»; && diu «fes allò només si això ha anat bé». En una neteja amb rm -r, aquesta diferència és la que separa un manteniment rutinari d'un incident.

Solució 3

!$ recupera l'últim argument de l'ordre anterior. Bash mostra la línia ja expandida abans d'executar-la, cosa que et deixa verificar que apunta on creus.

Per al punt 3, la seqüència amb dreceres:

1. Fletxa amunt dues vegades (o Ctrl+R i escriure acces) fins a recuperar ls -l /var/log/tramontana/acces.log.
2. Ctrl+W esborra l'última paraula, que en aquest cas és la ruta completa fins a l'espai anterior. Com que vols canviar només el nom del fitxer, és més net: Alt+B per retrocedir per paraules fins a situar-te sobre acces, esborrar aquesta paraula amb Alt+D i escriure errors.
3. Enter.

Amb noms llargs, Ctrl+A per anar al principi i Alt+F per avançar per paraules sol ser més ràpid que mantenir premuda la fletxa esquerra.

Per al punt 4:

Fixa't que l'ls d'Ubuntu mostra el nom entre cometes precisament per avisar-te que conté un espai.

Per què és mala idea en un servidor: el fitxer funciona perfectament mentre el manegis a mà amb Tab, però el dia que aparegui en un script sense cometes es trencarà, i ho farà de la pitjor manera possible: no fallant, sinó tractant informe i marta.txt com dues rutes. En un rm, això és un esborrat equivocat; en un bucle de còpia, un fitxer que no es copia. La convenció professional és informe-marta.txt o informe_marta.txt.

Ja no estàs mirant una pantalla negra: estàs manejant un intèrpret el funcionament del qual entens.

• La CLI és l'eina professional per reproduïble, automatitzable, remota i lleugera, no per tradició; i la seva contrapartida honesta és que no perdona ni avisa.
• El shell segueix un cicle REPL en què expandeix abans d'executar: el programa no veu mai exactament el que vas escriure.
• Una ordre té tres parts, les seves opcions poden ser curtes, agrupades, llargues o amb valor, i -- tanca la llista d'opcions.
• Hi ha builtins i externes; type -a és la teva eina de diagnòstic, i cd ha de ser builtin perquè cap fill no pot moure el seu pare.
• El shell localitza els executables recorrent el PATH en ordre, i el directori actual no hi és per raons de seguretat.
• Tab t'estalvia pulsacions i, sobretot, errades; Ctrl+R, !! i !$ t'estalvien reescriure; les dreceres de readline t'estalvien el retrocés interminable.
• ;, && i || són lògica de control, no puntuació: && és la teva opció per defecte quan una ordre depèn de l'anterior.
• Els espais als noms es protegeixen amb cometes simples, dobles o barra invertida, i el millor és no tenir-ne.

Amb això pots escriure ordres amb solvència. Falta l'altre pilar de l'autosuficiència: saber quines ordres existeixen i què fa cada opció sense dependre d'un cercador. A la propera lliçó, Obtenir Ajuda i Documentació del Sistema, aprendràs a llegir una pàgina de man de principi a fi, a entendre la notació del SYNOPSIS, a moure't per les vuit seccions del manual, a buscar una ordre quan ni tan sols en saps el nom, i a resoldre un dubte real d'en Luis Ferrer fent servir únicament el que ja hi ha instal·lat a srv-tramontana. És la lliçó que converteix «no ho sé fer» en «encara no ho sé».