Linux concept: shell

1. De basis

Een shell is een programma dat de opdrachten leest die je typt, uitzoekt wat je bedoelt en de rest van het systeem vraagt om ze uit te voeren. Het zit tussen jou en de kernel in. Je praat nooit rechtstreeks met de kernel; je praat met de shell, en de shell zorgt ervoor dat programma's namens jou draaien. Als mensen zeggen dat ze "op de command line" of "in een terminal" bezig zijn, is het programma waar ze echt tegen praten een shell.

De duidelijkste manier om het je voor te stellen is een simpele lus die nooit stopt terwijl je werkt. De shell toont een prompt, wacht tot je een regel typt, leest die regel, splitst hem in woorden, beslist wat te doen, voert het uit, toont de uitvoer en toont dan weer de prompt. Dit heet vaak de read-eval-lus, en het is de hele hartslag van interactief Unix:

print a prompt   ->   read a line   ->   understand it   ->   run it   ->   show output
      ^                                                                          |
      +--------------------------------------------------------------------------+

In die lus verschuilen zich twee verschillende taken, en het helpt om ze uit elkaar te houden. Als interactieve opdrachtinterpreter is de shell datgene waar je met de hand in typt. Als scripttaal leest exact hetzelfde programma opdrachten uit een bestand, zodat een lijst opdrachten een programma wordt dat je keer op keer kunt draaien. Het opmerkelijke aan Unix-shells is dat dit geen twee gereedschappen zijn: het is een programma dat hetzelfde werk doet met een andere bron van invoer.

Het juiste mentale model: de shell is een gewoon programma waarvan de hele taak is om andere programma's te draaien. Het is geen onderdeel van de kernel, het is niet "het systeem" - het is een vertaler die de regels die je typt omzet in verzoeken waar de kernel op kan reageren.

Dit artikel gaat over die vertaler: wat hij doet, waar de naam vandaan komt, hoe de shells van vandaag zijn ontstaan uit veertig jaar Unix-geschiedenis, hoe expansie en quoting echt werken, het verschil tussen een builtin en een echt programma, en de verrassende waarheid dat de shell, en niet de opdracht die je aanriep, het meeste slimme werk op je regel doet. De voorbeelden zijn geverifieerd tegen GNU Bash 5.2 op Linux.

1.1 Zien welke shell je draait

Je account heeft een login-shell, de shell die start wanneer je inlogt. De omgevingsvariabele SHELL legt vast welke dat is, en op de meeste Linux-systemen is dat Bash:

$ echo $SHELL
/bin/bash

Die variabele vertelt je je ingestelde shell, maar niet per se de shell die op dit exacte moment draait. Om de shell te vragen die op dit moment echt je opdrachten leest, kijk je naar $0, de naam van het draaiende programma:

$ echo $0
bash

Het verschil is belangrijker dan het lijkt. SHELL wordt eenmalig bij het inloggen ingesteld en verandert nooit; $0 geeft de shell weer waarin je je op dit moment bevindt, en die kan anders zijn als je met de hand een andere shell hebt gestart. Houd beide in gedachten: de een is je instelling, de ander is je werkelijkheid.

1.2 De shell is een bestand zoals elk ander

Een shell is niet magisch en niet ingebouwd in de kernel. Het is een gewoon uitvoerbaar programma dat op schijf staat, en je kunt het opsommen net als elk ander bestand:

$ ls -lh /bin/bash
-rwxr-xr-x 1 root root 1.4M ... /bin/bash

De lijst met shells die je systeem als geldige login-shells beschouwt, staat in een gewoon tekstbestand, /etc/shells:

$ cat /etc/shells
# /etc/shells: valid login shells
/bin/sh
/usr/bin/sh
/bin/bash
/usr/bin/bash
/usr/bin/dash

Elke regel is een programma dat als iemands shell kan dienen. Dat is de eerste hint naar iets waar we aan het eind op terugkomen: de shell is vervangbaar. Niets dwingt je om Bash te gebruiken, en het inruilen voor een ander programma in die lijst verandert het hele gevoel van je command line zonder het systeem eronder aan te raken.

1.3 De terminal is niet de shell

Twee woorden worden voortdurend door elkaar gehaald, en ze uit elkaar houden neemt veel verwarring weg. De terminal is het venster: een applicatie die tekst op je scherm tekent en je toetsaanslagen opvangt. De shell is het programma dat binnenin dat venster draait, die toetsaanslagen leest en je opdrachten uitvoert. De terminal is het glas; de shell is de stem erachter.

Het bewijs dat ze los van elkaar staan, is dat je ze vrij kunt combineren. Dezelfde Bash draait probleemloos in GNOME Terminal, Konsole of Alacritty, en elk van die terminals draait net zo makkelijk Zsh in plaats daarvan. Het duidelijkste geval is een login op afstand: als je verbinding maakt via SSH, is er op de andere machine helemaal geen terminal-emulator. Je lokale terminal tekent de tekst, maar de shell waarin je typt draait op de server, met niets dan een netwerkverbinding ertussen. De shell bezit geen venster; hij leest alleen invoer en schrijft uitvoer, en iets anders - een terminal, of SSH - brengt die naar je scherm.

3. Een korte geschiedenis

De shells die je vandaag gebruikt, zijn de huidige stap in een lange lijn die teruggaat tot het begin van Unix. Die lijn kennen verklaart waarom er meerdere shells zijn, waarom ze bijna maar net niet compatibel zijn, en waarom de standaardshell heet zoals hij heet.

De eerste Unix-shell werd rond 1971 geschreven door Ken Thompson bij Bell Labs. Hij kon opdrachten draaien en hun invoer en uitvoer omleiden, maar het was een klein gereedschap met bijna geen programmeermogelijkheden. Het echte keerpunt kwam in 1979, toen Stephen Bourne, ook bij Bell Labs, een veel krachtigere shell uitbracht met Version 7 Unix. Hij had variabelen, lussen, condities en functies - een echte programmeertaal - en behield de naam sh. Deze Bourne-shell werd het sjabloon waar elke latere shell zich aan afmat.

Rond dezelfde tijd schreef Bill Joy in Berkeley de C-shell (csh) voor BSD Unix, met een syntaxis die dichter bij de taal C lag en de eerste job control en opdrachtgeschiedenis. In 1983 combineerde David Korn bij Bell Labs het beste van beide werelden in de Korn-shell (ksh): de Bourne-taal plus de interactieve mogelijkheden van de C-shell.

Toen kwam de shell die de meeste Linux-gebruikers als eerste tegenkomen. In 1989 schreef Brian Fox Bash voor het GNU-project, als een vrije vervanger van de Bourne-shell. De naam is een woordgrap die je precies vertelt wat het is:

Bash staat voor "Bourne Again SHell" - een vrije herschrijving die "wedergeboren" is uit de Bourne-shell die hij vervangt. De grap is ook een belofte: hij spreekt de Bourne-taal, dus oude scripts blijven werken, terwijl er decennia aan nieuw interactief comfort bovenop komt.

Omdat Bash vrije software was en met GNU meekwam, werd het de standaardshell op bijna elke Linux-distributie, en daarom is het de shell die dit artikel gebruikt. De lijn stopte daar niet. Zsh, in 1990 geschreven door Paul Falstad, dreef de interactieve mogelijkheden het verst door en is nu de standaard op macOS. En dash, een kleine, snelle, strikt minimale shell, wordt op Debian en Ubuntu gebruikt als de gewone sh, omdat scripts die alleen de standaardtaal nodig hebben er sneller in draaien.

Een standaard bindt deze familie samen. POSIX definieert een gemeenschappelijke shell-taal, gebaseerd op de Bourne- en Korn-shells, die elke serieuze shell kan draaien. Schrijf een script volgens die standaard en het werkt in Bash, dash, ksh en zsh evengoed. Die gedeelde kern is de reden dat een twintig jaar geleden geschreven script nog steeds draait, en waarom sh een betekenisvolle naam is, ongeacht welk programma erachter zit.

5. Gemiddelde toepassingen

Zodra je de shell als interpreter ziet, is de volgende stap om hem je regel te zien herschrijven voordat er een opdracht draait. Tussen het moment dat je op Enter drukt en het moment dat een programma start, voert de shell een reeks transformaties uit die expansies heten. Het meeste van de kracht van de shell, en de meeste van zijn verrassingen, leven hier.

5.1 Expansie: de shell herschrijft je regel

Als je een regel typt, geeft de shell die niet ongewijzigd aan de opdracht door. Hij expandeert eerst verschillende soorten speciale tekst naar hun echte waarden. De belangrijkste zijn:

Hier is het kernpunt dat de meeste mensen missen: de opdracht ziet nooit wat je typte. Hij ziet het resultaat. Als je ls *.txt draait, krijgt het programma ls nooit iets over de * te horen. De shell expandeert *.txt eerst naar de daadwerkelijke lijst met bijpassende bestanden, en ls ontvangt die lijst als gewone argumenten:

$ ls *.txt
# the shell first turns *.txt into: notes.txt report.txt
# then runs:  ls notes.txt report.txt

Dit ene feit verklaart een groot deel van het Unix-gedrag, en we komen erop terug als de grootste verrassing in sectie 7.

5.2 Quoting: expansie uitzetten

Omdat de shell tekens als *, $ en spaties als speciaal behandelt, heb je een manier nodig om hem te zeggen "laat deze tekst met rust". Dat is wat quoting doet. Enkele aanhalingstekens zetten alle expansie uit; dubbele aanhalingstekens zetten het meeste uit maar expanderen nog steeds variabelen:

$ echo $HOME
/home/peter
$ echo "$HOME"        # double quotes: variable still expands
/home/peter
$ echo '$HOME'        # single quotes: taken literally
$HOME

Quoting is geen versiering; het is hoe je de shell bestuurt. De klassieke bug is een bestandsnaam met een spatie erin: zonder aanhalingstekens splitst de shell hem in twee argumenten. Zet een variabele tussen dubbele aanhalingstekens - "$file" - en de hele naam blijft bij elkaar. Dit is verreweg de meest voorkomende oorzaak van kapotte shell-scripts.

5.3 Pipes en omleiding: programma's verbinden

De andere grote kracht van de shell is loodgieterswerk. Elk programma start met drie stromen die al open zijn, en de shell kent ze zowel op nummer als op naam:

De shell laat je elk van deze stromen omleiden naar een bestand, of de uitvoer van het ene programma verbinden met de invoer van het volgende met een pipe, geschreven als |:

$ ls -l > listing.txt        # send output into a file (> means "write to")
$ ls -l >> listing.txt       # append instead of overwrite
$ sort < names.txt           # take input from a file (< means "read from")
$ ps aux | grep apache       # feed ps output straight into grep

De twee uitvoerstromen zijn met opzet gescheiden, zodat normale resultaten en foutmeldingen naar verschillende plekken kunnen gaan. Je stuurt stderr via zijn nummer, 2, en je kunt het samenvoegen met stdout met de speciale vorm 2>&1, wat betekent "stuur stroom 2 naar waar stroom 1 heen gaat":

$ command 2> errors.txt       # send only error messages to a file
$ command > out.txt 2>&1      # send output AND errors to the same file
$ command 2> /dev/null        # throw error messages away

Dit is het idee dat Unix maakt tot wat het is. Elk gereedschap doet een kleine taak en leest en schrijft platte tekst, en de shell klikt ze aan elkaar tot een pijplijn. De programma's weten niet dat ze verbonden zijn; de shell regelt de stromen zo dat de uitvoer van het ene de invoer van het volgende wordt. Bijna elke serieuze command line die je schrijft is een kleine pijplijn die de shell voor je in elkaar zet.

5.4 Builtins versus externe programma's

Als je een woord typt, kan de shell het op een van twee manieren draaien. De meeste opdrachten, zoals ls of grep, zijn losse programma's die de shell op schijf vindt en start. Maar sommige opdrachten zijn builtins: code die in de shell zelf zit en draait zonder een nieuw programma te starten. Bash heeft er ongeveer zestig:

$ type -a echo        # echo exists as both a builtin and a program
echo is a shell builtin
echo is /usr/bin/echo
$ type cd
cd is a shell builtin

Het onderscheid is niet zomaar weetjes. Sommige opdrachten moeten builtins zijn, omdat ze de shell zelf veranderen - en we zullen in sectie 7 precies zien waarom cd het klassieke voorbeeld is. Onthoud voor nu dat een builtin sneller is (er wordt geen nieuw programma gestart) en dingen kan die een programma van buiten niet kan.

7. Iets wat de meeste gebruikers niet weten

7.1 De shell expandeert je regel, niet de opdracht

Dit is verreweg het belangrijkste om te begrijpen over een Unix-shell, en de meeste mensen leren het bij toeval. Als je rm *.log draait, ziet het programma rm nooit de *. De shell expandeert *.log eerst naar de daadwerkelijke lijst met bijpassende bestandsnamen, en geeft die lijst dan aan rm. De opdracht heeft geen idee dat er ooit een wildcard bij betrokken was. Dit verklaart gedrag dat er anders vreemd uitziet: waarom * in een lege directory niets matcht en letterlijk wordt doorgegeven, waarom het quoten van een patroon het stopt met matchen, en waarom je wildcards kunt gebruiken met elke opdracht, zelfs die er niets van weten. De glob is het werk van de shell, gedaan voordat het programma start.

7.2 cd kan geen echt programma zijn

De opdracht die je huidige directory verandert, cd, moet een shell-builtin zijn - het kan onmogelijk een los programma zijn. Hier is waarom. Elk draaiend programma heeft zijn eigen huidige directory, en een programma kan de directory van zijn ouder niet veranderen. Als cd een extern programma was, zou de shell het starten, zou dat nieuwe programma zijn eigen directory veranderen en dan stoppen, en zou je shell precies staan waar hij begon. De wijziging zou verdwijnen met het programma dat hem maakte. De enige manier om de eigen directory van de shell te verplaatsen, is code binnen de shell draaien, en dat is precies wat een builtin is. Dit is de concrete reden waarom sommige opdrachten in de shell moeten leven in plaats van op schijf.

7.3 sh is waarschijnlijk niet de shell die je denkt

Op Debian en Ubuntu is /bin/sh niet Bash. Het is een symbolische link naar dash, een kleinere en striktere shell:

$ ls -l /bin/sh
lrwxrwxrwx 1 root root 4 ... /bin/sh -> dash

Dit is van belang op het moment dat een script alleen mislukt wanneer het als sh script wordt gedraaid. Bash accepteert stilletjes veel handige uitbreidingen die gewone sh niet accepteert, dus een script met #!/bin/sh dat een Bash-only functie gebruikt, werkt als je het in Bash test en breekt als het systeem het met dash draait. De les is de shebang te laten passen bij de taal die je echt schreef: gebruik #!/bin/bash als je op Bash-functies leunt, en #!/bin/sh alleen voor strikt standaard scripts.

7.4 De shell draait zelf bijna niets

Een interactieve shell is vooral een starter. Als je ls typt, somt de shell de directory niet op; hij vindt het programma ls, maakt een kopie van zichzelf met de system call fork, vervangt die kopie door ls met exec, en wacht tot het klaar is. Het beroemde fork-and-exec-patroon is het hart van hoe Unix programma's start, en de shell doet het voor bijna elke opdracht die je draait. De eigen code van de shell verzorgt de prompt, de expansies, de pipes en de builtins - en stapt dan opzij en laat een los programma het echte werk doen.

7.5 Je kunt je shell volledig vervangen

Omdat een shell gewoon een programma is dat in /etc/shells staat, ben je vrij om de shell die je bij het inloggen krijgt te veranderen. De opdracht chsh ("change shell") doet precies dat, en vanaf dan begroet elke terminal je met de shell die je koos:

$ chsh -s /usr/bin/zsh        # make zsh your login shell
$ echo $SHELL
/usr/bin/zsh

Daarom is de shell echt een buitenlaag en geen vast onderdeel van het systeem. Mensen stappen over van Bash naar Zsh voor de aanvulling, of gebruiken fish voor zijn vriendelijkheid, en niets eronder trekt zich er iets van aan: de kernel, de opdrachten en de bestanden zijn allemaal hetzelfde. Alleen het programma dat je opdrachten leest is veranderd, en dat is precies het hele punt van de shell als shell.

9. Veelgemaakte fouten

9.1 Mythe versus werkelijkheid

9.2 Andere valkuilen om te vermijden

• Variabelen ongequote laten. Een ongequote $file met een spatie erin wordt twee argumenten. Quote hem als "$file" tenzij je een specifieke reden hebt om het niet te doen.
• Aannemen dat de omgeving van een script blijft bestaan. Variabelen die binnen een script zijn ingesteld verdwijnen als het eindigt, omdat het script in zijn eigen shell draaide. Om je huidige shell te wijzigen, gebruik je source script in plaats van het te draaien.
• Vertrouwen dat #!/bin/sh Bash betekent. Test scripts met de shell die in de shebang staat, niet alleen interactief in Bash, anders mislukken ze mogelijk pas in productie.
• Vergeten dat expansie eerst gebeurt. Een gevaarlijke rm * is juist gevaarlijk omdat de shell * naar elk bestand expandeert voordat rm draait. Controleer eerst wat een glob matcht met echo *.
• $SHELL verwarren met de draaiende shell. $SHELL is je ingestelde login-shell; $0 is de shell die nu draait. Ze verschillen zodra je met de hand een andere shell start.
• Het verkeerde opstartbestand bewerken. Zet je een instelling in ~/.bashrc maar log je in via SSH en wordt hij genegeerd? Dat is de login-versus-non-login-valkuil uit sectie 6.1.