Dopo la fase di avvio, e prima che sia eseguito un programma, si può pensare al proprio computer come ad un contenitore di molti processi che stanno tutti aspettando qualcosa da fare. Stanno tutti aspettando degli eventi. Un evento può essere la pressione di un tasto o il movimento di un mouse. Oppure, se il proprio computer è collegato a una rete, un evento può essere un pacchetto di dati che arriva tramite quella rete.

Il kernel è uno di questi processi. È un processo speciale, perché controlla quando gli altriprocessi utente possono essere eseguiti, ed è normalmente l'unico processo con accesso diretto all'hardware del computer. Infatti, i processi utente devono fare richiesta al kernel quando vogliono ottenere un input dalla tastiera, scrivere sullo schermo, leggere o scrivere sul disco, o fare solo qualsiasi altra cosa che non sia macinare bit in memoria. Queste richieste sono conosciute come chiamate di sistema.

Normalmente tutto l'I/O passa attraverso il kernel, così quest'ultimo può organizzare le operazioni e impedire che i processi si ostacolino a vicenda. Alcuni processi utente speciali hanno il permesso di aggirare il kernel, di solito per ottenere accesso diretto alle porte I/O. I server X sono gli esempi più comuni di questo fatto.

Si potranno eseguire i programmi in uno dei due modi: attraverso il proprio server X o attraverso una shell. Spesso, abitualmente si farà da entrambi, dato che si avvierà un emulatore di terminale che imita una console testuale vecchio stile, fornendo una shell per eseguire i programmi da essa. Descriverò che cosa succede quando si fa questo, poi ritornerò a cosa succede quando si esegue un programma attraverso un menu di X o una icona del desktop.

La shell è così chiamata perché essa avvolge completamente e nasconde il kernel del sistema operativo. È una importante caratteristica di Unix che la shell e il kernel siano programmi separati che comunicano attraverso un piccolo insieme di chiamate di sistema. Questo rende possibile che ci siano shell multiple, che si adattano a differenti gusti nelle interfacce.

La shell normale fornisce il prompt ‘$’ che si vede dopo il login (a meno che non lo abbiate personalizzato per essere qualcosa d'altro). Non parleremo della sintassi della shell e delle cose semplici che si possono vedere sullo schermo; daremo piuttosto uno sguardo dietro le quinte a quello che succede dal punto di vista del computer.

La shell è solo un processo utente, e neppure uno tanto speciale. Attende che si digiti qualcosa, ascoltando (tramite il kernel) sulle porte I/O della tastiera. Come il kernel vede che è stato digitato qualcosa lo visualizza sulla propria console virtuale o emulatore di terminale di X. Quando il kernel vede un ‘Invio’ passa la propria linea di testo alla shell. La shell tenta di interpretare la pressione di questi tasti come dei comandi.

Supponiamo che si digiti ‘ls’ e Invio per invocare il programma Unix che elenca le directory. La shell applica le sue regole incorporate per cercare di capire che si vuole eseguire il comando eseguibile nel file /bin/ls. Essa fa una chiamata di sistema chiedendo al kernel di avviare /bin/ls come un nuovo processo figlio e gli fornisce un accesso allo schermo e alla tastiera tramite il kernel. Poi la shell riposa, aspettando che ls finisca.

Quando /bin/ls ha finito, comunica al kernel che ha terminato emettendo una chiamata di sistema exit. Il kernel allora attiva la shell e le comunica che può continuare a funzionare. La shell emette un altro prompt e attende un'altra linea di input.

Potrebbero succedere altre cose mentre il proprio comando ‘ls’ è in esecuzione, tuttavia (supponiamo che si stia elencando una directory molto lunga). Per esempio, si potrebbe passare ad un'altra console virtuale, fare il log in da questa console, e iniziare un gioco di Quake. Oppure si supponga di essere collegati a Internet. Il proprio computer potrebbe spedire o ricevere posta mentre /bin/ls è in esecuzione.

Quando si eseguono programmi attraverso il server X invece che da una shell (cioè, scegliendo una applicazione da un menu a scomparsa, o facendo doppio click (con il mouse) su di una icona del desktop), ognuno dei diversi programmi associati con il proprio server X può comportarsi come una shell e lanciare il programma. Vorrei sorvolare sui dettagli dato che sono sia variabili che poco importanti. Il punto fondamentale è che il server X, diversamente da una normale shell, non va a dormire mentre il programma client è in esecuzione — invece, si posiziona tra voi e il client, passando i propri click del mouse e la pressione dei tasti ad esso e soddisfando le sue richieste di puntamento di pixel sul proprio schermo.