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^9.1. 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 :

144#144

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:

145#145

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:

146#146

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.

147#147

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:

148#148

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 4#4, 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:

149#149

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:

150#150

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

151#151

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^9.2. 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:

152#152

  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:

153#153

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

154#154

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:

155#155

  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 PATH è un po' lungo.

156#156