Abbiamo capito che la shell è uno strumento molto potente... cominciamo a usarla. Tanto per cominciare, chiediamoci in quale directory ci troviamo. Ipotizzo che l'utente in questione abbia come username pratesi e per semplicità abbrevio il prompt della shell con il solo simbolo del dollaro ($); in genere il prompt del ``root'' è contrassegnato da un cancelletto (#). In tal caso, se batto il comando
$ pwd(Print Working Directory) ottengo la risposta
/home/pratesiCommentiamo un po' tutto ciò. Ciascun utente ha una home directory, che è la propria ``casa'' sul computer utilizzato. A partire da essa, può creare file, directory, sottodirectory e tutto ciò che gli serve per il suo lavoro. Appena l'utente completa con successo la procedura di login fornendo la propria username e la propria password, il sistema avvia per lui la shell che gli è stata assegnata (come già detto, su Linux di default si tratta della bash) e come directory corrente (working directory) gli assegna la sua home directory. Di default, su Linux la home directory è /home/[username], anche se l'amministratore può facilmente fare scelte diverse.
A questo punto, proviamo a chiedere al sistema quali file sono a disposizione dell'utente, tramite il comando
$ ls(List); nel caso del mio computer di casa, ottengo la risposta
99-0061 Images VTC98 kde.tgz AAA LEZIONE WPERFECT lib ANTONELLA LINUX X11 mp.fvwmrc CASO-1.0 LUTZCHANNEL Xrootenv.0 notes.tar CASO-1.01 MARZO96 appunti.aux nsmail DOCUMENTI Office50 appunti.dvi pippo.html DONATI PASS appunti.log pippo.tex Desktop POSTA appunti.tex pratesi.tgz FIGURE SYA-1.0 archivio snapshot02.gif FSMAGGIO97 SYA-1.1 cernobyl.txt standards GENNAIO97 TCP-IP file_select.vim startkde GNUstep TESI gnm sya11.tgz IBM TESI.LAUREA.PS include wladyQuesta risposta comprende l'elenco delle directory (in genere per queste ultime uso un nome che comincia con una lettera maiuscola) e dei file che si trovano nella mia home directory. Ovviamente si tratta di un computer su cui lavoro già da tempo, su cui quindi ho già prodotto del materiale. Appena l'utente viene creato, la sua home directory è praticamente vuota, a parte qualche file di configurazione, di solito nascosto, cioè il cui nome comincia con un punto. Normalmente il comando ls non elenca i file nascosti; per farlo bisogna usare l'opzione -a (All). Usando il comando
$ ls -aOttengo la risposta
. .nedit FIGURE appunti.dvi .. .neditdb FSMAGGIO97 appunti.log .Xdefaults .netscape GENNAIO97 appunti.tex .acrorc .rhosts GNUstep archivio .amaya .seyon IBM cernobyl.txt .bash_history .sversionrc Images file_select.vim .bash_logout .thotrc LEZIONE gnm .bash_profile .user.rdb LINUX include .bashrc .vimrc LUTZCHANNEL kde.tgz .dcon .weblink MARZO96 lib .ddd .wmrc Office50 mp.fvwmrc .fvwmrc .wprc PASS notes.tar .gimp .xfig POSTA nsmail .gp_history .xinitrc SYA-1.0 pippo.html .gv .xsession-errors SYA-1.1 pippo.tex .gvimrc 99-0061 TCP-IP pratesi.tgz .inputrc AAA TESI snapshot02.gif .kaudioserver ANTONELLA TESI.LAUREA.PS standards .kde CASO-1.0 VTC98 startkde .kde.bak CASO-1.01 WPERFECT sya11.tgz .kderc DOCUMENTI X11 wlady .lista_file.txt DONATI Xrootenv.0 .mc Desktop appunti.auxche, ovviamente, accanto ai file nascosti, elenca anche quelli già visti prima.
Ora cerchiamo di essere selettivi. i file appunti.aux, appunti.dvi, appunti.log e appunti.tex corrispondono a degli appunti prodotti con LATEX; appunti.tex è il file sorgente, gli altri vengono prodotti tramite ``compilazione'', in particolare appunti.dvi è in un formato adatto al ``preview''. Per elencare solo questi 4 file si può usare il comando
$ ls appunti.*Ottenendo la risposta
appunti.aux appunti.dvi appunti.log appunti.texappunti.* indica tutti i file il cui nome comincia con appunti e un punto e continua con un numero qualunque (anche pari a 0) di caratteri qualsiasi. Nel caso in questione si potrebbe ottenere lo stesso risultato essendo più concisi, con il comando
$ ls app*dato che solo i 4 file in questione hanno un nome che comincia con app.
Ci si potrebbe chiedere perché i nomi dei comandi visti sono così corti e, quindi, anche difficili da ricordare per un nuovo utente. Si potrebbe rispondere che dover digitare comandi lunghi potrebbe essere fastidioso per l'utente esperto, ma questo è vero fino a un certo punto. Infatti, una volta digitato un numero di caratteri sufficiente a individuare univocamente il comando desiderato, si può premere il tasto TAB: la shell lo completa al posto dell'utente. Se le lettere digitate non sono sufficienti, la shell non completa il nome; si può digitare qualche altra lettera e riprovare, oppure premere due TAB consecutivi in maniera sufficientemente rapida: la shell risponde elencando tutti i comandi che iniziano con le lettere digitate. Lo stesso vale per i nomi dei file, del resto i comandi non sono altro che dei file eseguibili con lo stesso nome del corrispondente comando (ovvio, no?). Quindi comandi con nomi lunghi non sarebbero un problema; bisogna però ricordare che le origini di UNIX risalgono a ben trent'anni fa, quando i terminali erano piuttosto lenti e rendevano conveniente l'uso di nomi corti. Ciò che è stato prodotto in tempi più recenti può senz'altro venir meno a tale criterio.
A questo proviamo a cambiare directory di lavoro con il comando cd (Change Directory):
$ cd CASO-1.01Questo comando mi porta nella directory corrispondente; infatti, se chiedo al sistema qual è la directory corrente di lavoro,
$ pwdOttengo la risposta
/home/pratesi/CASO-1.01Quindi, battendo il comando
$ lssi ottiene l'elenco dei file della directory /home/pratesi/CASO-1.01:
Makefile mprv.c mprv.h test
Proviamo a utilizzare il comando ls con un'altra opzione, che aprirà un altro discorso (parlare di UNIX è difficile proprio per questo: come indirizzare e confinare la discussione se si parla di qualcosa così potente? ;-). Più precisamente, usiamo l'opzione -l (Long):
$ ls -lUNIX risponde
-rw-r--r-- 1 pratesi pratesi 468 Feb 18 19:20 Makefile -rw-r--r-- 1 pratesi pratesi 1365 Feb 5 23:14 mprv.c -rw-r--r-- 1 pratesi pratesi 278 Feb 5 23:14 mprv.h drwxr-xr-x 2 pratesi pratesi 1024 Apr 6 21:50 testPer commentare tutto ciò ci vuole un po'. Innanzitutto, l'ultima colonna corrisponde ancora ai nomi dei file della directory corrente; procedendo a ritroso, si incontrano, rispettivamente, l'ora, il giorno e il mese di ultima modifica dei file in questione. Quindi si incontra la dimensione del file, espressa in byte. A questo punto bisogna fare una precisazione sull'identità dell'utente. Su UNIX, ogni utente, oltre a un nome, ha un gruppo di appartenenza. Questo rispecchia l'ambiente in cui UNIX è nato: nei laboratori Bell si lavorava ai vari progetti per gruppi (niente di strano, no?). Su Linux RedHat, quando viene creato un nuovo utente, come scelta di default viene creato un nuovo gruppo con il suo stesso nome; mi sembra una scelta discutibile, tuttavia sul computer di casa, essendoci solo l'utente pratesi, questo non mi crea problemi, quindi ho accettato tutto ciò. Procedendo verso sinistra con l'analisi delle varie colonne, si incontrano il gruppo e l'utente a cui appartengono il file. Il file è di pratesi, quindi è normale che appartenga al suo gruppo; tuttavia UNIX permette di modellare situazioni di lavoro ben più complesse e un utente può appartenere a più gruppi di utenti contemporaneamente. Per evitare di aprire un discorso troppo ampio, direi di fermarsi alle considerazioni fatte. La colonna ancora successiva corrisponde al numero di hard links del file: direi di sorvolare anche su questo. Analizziamo la colonna più a sinistra relativa all'ultimo file. Essa indica dei permessi d'accesso relativi a test. La prima lettera, ``d'' indica che il file in questione è una directory. Seguono altre 9 caratteri da vedere come 3 insiemi di 3 caratteri. Il primo insieme riguarda il possessore del file, il secondo il gruppo e il terzo il resto del mondo. Consideriamo il primo gruppo: rwx indica che nella directory test il possessore, pratesi, ha diritto di lettura (r sta per Read), scrittura (w sta per Write) ed esecuzione di comandi (x sta per eXecute). Se si trattasse di un file ``normale'', anziché di una directory, i caratteri rwx indicherebbero che il possessore ha il diritto di leggere, scrivere (quindi modificare e/o rimuovere) il file, ed eseguirlo; per esempio, il permesso di esecuzione può riguardare i file binari ottenuti tramite compilazione di codice in linguaggio C, oppure gi script di shell. Il secondo insieme di 3 caratteri ha lo stesso significato, ma riguarda gli utenti che fanno parte del gruppo indicato nell'apposita colonna; in questo caso riguarda eventuali altri utenti appartenenti al gruppo pratesi. r-x indica che tali utenti hanno il diritto di lettura e di esecuzione nella directory test, nella quale però non hanno il diritto di scrittura. Questo vuole dire che tali utenti non possono creare, modificare e/o rimuovere file nella directory in questione. Se le tre lettere in questione fossero -x, gli utenti in questione avrebbero diritto di esecuzione su tale directory: potrebbero accedervi e da lì lanciare vari comandi di sistema, ma non avendo il diritto di lettura non potrebbero neanche elencare i file in essa contenuti tramite il comando ls. Nel caso di assenza del diritto di esecuzione, non potrebbero neanche accedere alla directory tramite il comando cd.
Il comando chmod (CHange MODe) permette di modificare i permessi di accesso a file e directory (in definitiva, una directory è solo un tipo particolare di file). Esistono vari modi di usarlo, facciamo un esempio molto comune. Supponiamo di dare il comando
$ chmod 400 MakefileUNIX risponde semplicemente restituendoci la linea di comando. Ma che cosa abbiamo fatto esattamente? Si può intuire che abbiamo modificato i permessi di accesso del file Makefile. E 400 che cosa indica? Va letto come una sequenza di 3 cifre: 4, 0 e 0. La prima cifra riguarda il possessore del file, la seconda il suo gruppo e la terza il resto del mondo. Consideriamo la prima cifra, il 4, e vediamola scritta in base 2: 100. Queste 3 cifre binarie sono in corrispondenza con i permessi di lettura, scrittura ed esecuzione, cioè rwx, e indicano che l'unico permesso che va lasciato ``acceso'' è quello di lettura. A questo punto si capisce facilmente che i due zeri nel comando dato servono a non lasciare nessun permesso di accesso al file da parte degli altri utenti del gruppo e dal parte del resto del mondo. In definitiva, abbiamo ridotto i permessi di accesso al file, che prima potevano essere riassunti dalle cifre ottali 644. Perché si può voler fare questo? In un sistema multiutente come UNIX, l'eliminazione dei diritti di accesso da parte degli altri può avere motivazioni ovvie, ma ridurli per se stessi... Su un Makefile, che può ad esempio servire per una compilazione ordinata di codice C, il permesso di esecuzione non ha molto senso: esso contiene informazioni utili per un altro programma, il make. Riguardo all'eliminazione del permesso di scrittura, potremmo voler evitare di rimuoverlo per errore.
In generale, non è possibile modificare i permessi di accesso a qualunque file: ognuno pensi ai suoi. Fa eccezione, per ovvi motivi, il root, cioè l'amministratore di sistema, la cui azione non ha limiti in nessun caso. Accanto a chmod, esistono i comandi chown e chgrp, che servono a modificare il possessore e il gruppo di un file o di una directory. Non è possibile affrontarli in questo contesto in maniera sufficientemente concisa, dato che, ad esempio, anche per motivi di sicurezza, un utente comune non può modificare il gruppo di un suo file, a meno che egli non appartenga al gruppo in questione. In generale, solo il root può utilizzare senza limitazioni tali comandi. Infine, i permessi di accesso manipolabili dal root sono più complessi: in particolare, fanno riferimento a 4 cifre ottali anziché 3. Per ovvie ragioni di brevità, tralasciamo questo aspetto che non è indispensabile per chi usa una distribuzione di Linux semplice come RedHat e non ha bisogno di fare grosse modifiche al sistema che si trova davanti subito dopo l'installazione.