Personalizzare bash

Una delle caratteristiche della filosofia di Unix è che l'impostazione del sistema non vuole prevedere tutte le necessità dell'utente; tenta invece di rendere semplice per ciascuno modificarsi l'ambiente a seconda delle proprie necessità. Per questo vengono usati principalmente dei file di configurazione . Questi file sono noti anche come ``file init'' , ``file rc''  (per ``run control'', controllo dell'esecuzione) o anche ``file punto'' , perché il loro nome di solito inizia con ``.''. Se vi ricordate, i file che hanno il nome che inizia con ``.'' non vengono normalmente visualizzati da ls.

I file di configurazione più importanti sono quelli utilizzati dalla shell. La shell di default di Linux è bash , ed è di questa che parleremo in questo capitolo. Prima di vedere come personalizzare bash, bisogna sapere quali file utilizza.

Avvio della shell

Ci sono diversi modi in cui può essere eseguita bash, ad esempio come shell di login , che è come viene eseguita al login. La shell di login dovrebbe essere la prima che vedete.

Un'altra modalità in cui si esegue bash è come shell interattiva : una shell qualsiasi che presenti un prompt all'utente ed aspetti dei comandi. Una shell di login è anche interattiva. Un modo per ottenere una shell interattiva non di login è per esempio una shell all'interno di un xterm . Qualsiasi shell che viene creata in modo diverso dal login è una shell non di login.

Infine ci sono le shell non interattive , che sono usate per eseguire dei file di comandi, più o meno come i file batch di MS-DOS --quelli che finiscono in .BAT. Questi script di shell  funzionano come dei mini-programmi; anche se sono generalmente molto più lenti di un normale programma compilato, è spesso vero che sono molto più semplici da scrivere.

A seconda del tipo di shell, al suo avvio vengono usati diversi file:

File di avvio

Dato che la maggior parte degli utenti vogliono avere lo stesso ambiente in qualsiasi shell, interattiva, di login o no, iniziamo con un comando molto semplice da mettere nel file .bash_profile: ``source ~/.bashrc''. Il comando source  dice alla shell di interpretare l'argomento come uno script di shell. Per noi questo significa che ogni volta che viene eseguito .bash_profile, viene eseguito anche .bashrc.

Ora aggiungeremo semplicemente dei comandi al file .bashrc. Se volete che un comando sia valido solo per una shell di login, aggiungetelo a .bash_profile.

Aliasing

 

Quali sono le cose che volete personalizzare? Ecco qualcosa che credo si trovi nel .bashrc del 90% degli utenti di Bash:

Questo comando ha definito un alias  di shell con nome ll, che, quando viene richiamato dall'utente, si ``espande'' nel normale comando di shell ``ls -l''. Quindi, assumendo che Bash abbia letto quel comando dal file .bashrc, potete digitare semplicemente ll per avere l'effetto di ``ls -l'' nella metà delle digitazioni. Quello che accade è che quando digitate ll e premete , Bash lo intercetta, dato che si aspetta degli alias, e lo sostituisce con ``ls -l''. In realtà non c'è nessun programma che si chiama ll sul sistema, ma la shell traduce automaticamente l'alias in un programma valido.

Alcuni alias di esempio sono riportati in Figura . Li potete aggiungere al vostro .bashrc. Un alias particolarmente interessante è il primo. Con quell'alias, quando qualcuno digita ls, automaticamente viene aggiunta l'opzione -F (l'alias non prova ad espandersi di nuovo). È un modo abbastanza comune per aggiungere delle opzioni che usate ogni volta che richiamate un programma.

Notate i commenti con il carattere # nella Figura . Quando appare un #, la shell ignora il resto della linea. 

  
Figure: Degli esempi di alias per bash.

Potreste aver notato alcune strane cose su questi alias: ad esempio, in alcuni ho tralasciato le virgolette--come in pu. Rigorosamente parlando, le virgolette non sono necessarie quando avete solo una parola a destra del segno di uguale.

Non è che mettere le virgolette faccia male, quindi non prendete cattive abitudini: dovreste usarle di sicuro se state per fare un alias di un comando con delle opzioni e/o argomenti:

Inoltre, l'alias finale ha dei caratteri strani:

Come potete aver indovinato, volevo passare le virgolette nelle opzioni stesse, quindi le ho dovute far precedere da una barra rovesciata in modo da evitare che bash pensasse che volevo segnalare la fine dell'alias.

Infine, ho messo come alias due comuni errori di battitura, ``mroe'' e ``moer'', per il comando esatto, more. Gli alias non interferiscono con gli argomenti passati ad un programma. Funziona lo stesso se scrivete:

In effetti, sapere come creare gli alias è probabilmente almeno metà della personalizzazione della shell che farete mai. Sperimentate, scoprite quali comandi lunghi date spesso, e createne degli alias. Scoprirete che rende molto più piacevole lavorare al prompt della shell.

Variabili d'ambiente

 

Un'altra cosa importante che si può fare nel file .bashrc è impostare le variabili d'ambiente . E che cosa sono? Prendiamola da un'altra direzione: supponiamo che stiate leggendo della documentazione per il programma pippo, ed incontrate queste frasi:

Pippo normalmente cerca il suo file di configurazione, .pipporc, nella home directory dell'utente. Comunque, se la variabile d'ambiente PIPPOPATH è impostata ad un nome di file diverso, cercherà lì.

Ogni programma viene eseguito in un ambiente  definito dalla shell che ha chiamato il programma. Si può dire che l'ambiente esiste ``all'interno'' della shell. I programmatori hanno una routine speciale per porre delle domande all'ambiente, e il programma ``pippo'' usa questa routine: controlla il valore della variabile d'ambiente PIPPOPATH; se la variabile non è definita, userà semplicemente il file .pipporc nella home directory. Se è definita, comunque, pippo userà il valore della variabile (che dovrebbe essere il nome di un file che pippo può usare) al posto del default .frugglerc.

Ecco come si può cambiare l'ambiente in bash :

Si può pensare al comando export come ad un invito: ``Per favore, esporta questa variabile all'ambiente, dove richiamerò i programmi, in modo che il suo valore sia a loro visibile.'' Ci sono delle buone ragioni per chiamarlo export, come vedremo poi.

Questa particolare variabile viene usata dal famoso programma di criptazione a chiave pubblica di Phil Zimmerman  pgp . Normalmente pgp cerca determinati file di cui ha bisogno (che contengono le chiavi di criptazione) nella home directory, e la usa anche per registrare i file temporanei che crea mentre è in funzione. Impostando la variabile PGPPATH a questo valore, gli ho detto di usare la directory /home/larry/secrets/pgp. Ho dovuto leggere il manuale di pgp per trovare il nome esatto della variabile e che cosa fa, ma è abbastanza standard l'uso del nome del programma in lettere maiuscole, seguito dal suffisso ``PATH''.

È anche utile saper chiedere informazioni sull'ambiente:

Notate il ``$'': si premette un segno di dollaro al nome di una variabile d'ambiente per estrarre il valore della variabile. Se aveste scritto il comando senza il segno di dollaro, echo avrebbe semplicemente stampato i suoi argomenti:

Il ``$'' viene usato per valutare le variabili d'ambiente, ma lo fa solo nel contesto della shell--cioè, quando è la shell che interpreta i comandi. Quando è che lo fa? Beh, quando state digitando dei comandi al prompt, o quando bash sta leggendo dei comandi da un file come .bashrc si può dire che è la shell che ``interpreta'' i comandi.

C'è un altro comando molto utile per rivolgere domande all'ambiente: env . env elencherà semplicemente tutte le variabili d'ambiente. È possibile, specialmente se state usando X, che l'elenco scorra fuori dallo schermo; se succede, mandate l'output di env, con una pipe, a more: env | more.

Alcune di queste variabili sono piuttosto utili, quindi le descriveremo più dettagliatamente. Guardate la Figura . Queste quattro variabili sono definite automaticamente quando fate login: non c'è bisogno di impostarle nei file .bashrc o .bash_login.

  
Figure: Alcune importanti variabili d'ambiente.

Diamo un'occhiata più da vicino alla variabile TERM . Per capirla, torniamo un attimo alla storia di Unix: il sistema operativo ha bisogno di conoscere alcune cose sulla vostra console, per poter attivare delle funzioni di base come scrivere un carattere sullo schermo, spostare il cursore sulla linea seguente, eccetera. Nei primi anni dell'informatica, i produttori di computer aggiungevano continuamente nuove caratteristiche ai terminali: per prima l'inversione, poi forse i caratteri europei, e alla fine magari anche delle primitive funzioni grafiche (ricordatevi, ancora non esistevano i sistemi a finestre ed i mouse!). Comunque, tutte queste nuove funzioni rappresentavano un problema per i programmatori: come potevano sapere quali funzioni aveva un terminale, e quali no? E come potevano supportare le nuove caratteristiche senza far diventare inutili i vecchi terminali?

In Unix, la risposta a queste domande è stata /etc/termcap . /etc/termcap è un elenco di tutti i terminali che il vostro sistema conosce, e come controllano il cursore. Se un amministratore di sistema comprava un nuovo tipo di terminale, tutto quello che doveva fare era aggiungere una voce per quel terminale in /etc/termcap invece di ricompilare tutto Unix. Talvolta è ancora più facile: lungo la strada, il vt100  della Digital Equipment Corporation  è diventato quasi uno standard, e molti terminali nuovi sono stati costruiti in modo da poterlo emulare, o da potersi comportare come un vt100.

Sotto , il valore di TERM è talvolta console, che è un terminale di tipo vt100 con delle caratteristiche aggiunte.

  Anche un'altra variabile, PATH, è cruciale per il funzionamento corretto della shell. Ecco la mia:

Il vostro PATH è un elenco, con le voci separate da due punti, delle directory in cui la shell deve cercare i programmi, quando digitate il nome di un programma da eseguire. Quando digito ls e premo , per esempio, Bash guarda per prima cosa in /home/larry/bin, una directory che ho creato per i programmi scritti da me; ma io non ho creato ls (in effetti, credo che sia stato scritto prima che io nascessi!). Non trovandolo in /home/larry/bin, Bash cerca in /bin--e lì lo trova. /bin/ls esiste ed è eseguibile, quindi Bash interrompe la ricerca e avvia il programma. Ci poteva essere un altro programma con nome ls nella directory /usr/bin, ma Bash non l'avrebbe mai avviato a meno che io non avessi specificato esplicitamente il percorso:

Lo scopo della variabile PATH è di non farci digitare i percorsi completi ogni volta che dobbiamo dare un comando. Quando digitate un comando, Bash lo cerca nelle directory elencate in PATH, in ordine, e se lo trova lo avvia. Se non lo trova, vi dà un errore:

Notate che nel mio PATH non c'è la directory corrente, `` .''. Se ci fosse stata, sarebbe stato così:

Questo è un problema su cui si dibatte nei circoli Unix (di cui siete membri adesso, che vi piaccia o no). Il problema è che avere la directory corrente nel percorso può essere un buco di sicurezza. Supponiamo che facciate cd in una directory in cui qualcuno abbia lasciato un programma ``Trojan Horse'' con nome ls, voi fate un ls, come sarebbe naturale entrando un una nuova directory. Dato che la directory corrente, ``.'', è la prima del vostro PATH, la shell troverebbe questa versione di ls e la eseguirebbe. Qualsiasi cattiveria ci fosse in quel programma, l'avreste appena eseguita (e può essere molto cattiva!). Non ci sarebbe bisogno di privilegi di root per farlo; basterebbe un permesso di scrittura sulla directory in cui si trova il ``falso'' ls. Potrebbe essere anche la loro home directory, se avessero saputo che ci sareste capitati dentro.

Sul vostro sistema è molto poco probabile che la gente si lasci delle trappole l'un l'altro. Tutti gli utenti sono probabilmente vostri amici o colleghi. Comunque, su grandi sistemi multi-utente (come molti computer delle università), ci possono essere programmatori poco amichevoli che non avete mai incontrato. Se volete o no che nel vostro percorso ci sia ``.'' dipende dalla situazione; non sarò dogmatico sull'una o sull'altra scelta, ma vorrei che aveste presenti i rischi. I sistemi multi-utente sono come delle comunità, dove c'è gente che si può comportare in modo imprevedibile.

Il mio PATH è in realtà impostato in un modo che riassume la maggior parte delle cose che avete imparato finora sulle variabili d'ambiente. Ecco cosa c'è nel mio .bashrc:

  Qui mi avvantaggio del fatto che la variabile HOME viene impostata prima che Bash legga il file .bashrc, ed uso il suo valore nell'impostazione del PATH. Le parentesi graffe (`` {...}'') sono un ulteriore livello di quoting: delimitano l'estensione di quello che il ``$'' deve valutare, in modo che la shell non si confonda con il testo seguente (nel nostro caso `` /bin''). Ecco un altro esempio del loro effetto:

Senza le parentesi, non avrei niente, dato che non esiste una variabile d'ambiente che si chiama HOMEfoo.

Fatemi chiarire un'altra cosa sulla mia impostazione della variabile: il significato di ``$PATH'': quello che fa è includere il valore di qualsiasi variable PATH impostata precedentemente. Dove sarebbe impostata una variabile del genere? Il file /etc/profile fa da .bash_profile globale, comune a tutti gli utenti; avere un file centralizzato del genere aiuta il sistemista ad aggiungere nuove directory al PATH di tutti gli utenti, senza dover farlo uno per uno. Se includete il vecchio path nel vostro, non perderete nessuna directory utile.

Potete anche controllare l'aspetto del prompt: si fa impostando il valore della variabile d'ambiente PS1. Personalmente preferisco un prompt che mi faccia vedere il percorso della directory corrente--ecco come faccio:

  Come potete vedere, qui vengono usate due variabili. Quella che viene impostata è la variabile PS1, e viene impostata al valore della variabile PWD, che può significare sia ``Print Working Directory'' sia ``Path to Working Directory''. La valutazione di PWD avviene all'interno degli apici. Gli apici servono per valutare l'espressione tra essi contenuta, che in questo caso viene valutata come la variabile PWD. Se aveste fatto solo export PS1=$PWD, il prompt avrebbe contenuto sempre il percorso alla directory corrente al momento in cui avevate impostato PS1, invece di aggiornarlo continuamente quando si cambia directory. Beh, è un po' confuso, e non è poi così importante. Tenete solo a mente che se volete che nel prompt sia mostrata la directory corrente vi servono gli apici.

Potreste preferire export PS1='$PWD>', o anche il nome del sistema: export PS1=`hostname`'>'; fatemi sezionare quest'ultimo esempio un po' meglio.

Nell'ultimo esempio ho usato un nuovo tipo di quoting, quello con gli apici rovesciati: non protegge niente--in effetti, noterete che ``hostname'' non appare da nessuna parte nel prompt. Quello che accade è che il comando all'interno degli apici rovesciati viene valutato, e il suo output viene mostrato al posto degli apici e del nome del comando.

Provate a fare echo `ls` o wc `ls`. A mano a mano che acquistate esperienza nell'uso della shell, questa tecnica diventa sempre più potente.

 

Ci sono parecchie altre cose che si possono configurare nel .bashrc, e qui non c'è spazio per spiegarle tutte. Potete leggervi la pagina di manuale di bash, o chiedere a chi ne sa di più. Ecco un file .bashrc completo da studiare: è piuttosto standard, anche se il percorso è un po' lungo.