Variabili d'ambiente: parte II

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

/home/larry# env | grep ^PATH
PATH= /home/larry/bin: /bin: /usr/bin: /usr/local/bin: /usr/bin/X11: /usr/TeX/bin
/home/larry#

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:

/home/larry# /usr/bin/ls

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:

/home/larry# clubly
clubly: command not found

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

/home/larry# echo $PATH
.: /home/larry/bin: /bin: /usr/bin: /usr/local/bin: /usr/bin/X11: /usr/TeX/bin
/home/larry#

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 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 (ricordatevi che potete sempre eseguire i programmi nella directory corrente dandogli il percorso esplicito, come ./foo). 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:

export PATH=${PATH}: .: ${HOME}/bin: /bin: /usr/bin: /usr/local/bin: /usr/bin/X11: /usr/TeX/bin

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:

/home/larry# echo ${HOME}foo
/home/larryfoo
/home/larry#

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

/home/larry# echo $HOMEfoo

/home/larry#

Fatemi chiarire un'altra cosa sulla mia impostazione della variabile: il significato di "$PATH". Quello che fa è includere il valore di qualsiasi variabile 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:

export PS1='$PWD#'

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.

# varie:
ulimit -c unlimited
export history_control=ignoredups
export PS1='$PWD>'
umask 022

# percorsi specifici per le applicazioni:
export MANPATH=/usr/local/man:/usr/man
export INFOPATH=/usr/local/info
export PGPPATH=${HOME}/.pgp

# il PATH principale:
homepath=${HOME}:~/bin
stdpath=/bin: /usr/bin: /usr/local/bin: /usr/ucb/: /etc: /usr/etc: /usr/games
pubpath=/usr/public/bin: /usr/gnusoft/bin: /usr/local/contribs/bin
softpath=/usr/bin/X11: /usr/local/bin/X11: /usr/TeX/bin
export PATH=.:${homepath}:${stdpath}:${pubpath}:${softpath}
# Tecnicamente, le parentesi graffe non erano necessarie,
# perche' i due punti sono delimitatori validi;
# comunque, e' una buona abitudine abituarsi
# a mettere le parentesi, che non fanno mai male.

# alias
alias ls="ls -CF"
alias fg1="fg %1"
alias fg2="fg %2"
alias tba="talk sussman@tern.mcs.anl.gov"
alias tko="talk kold@cs.oberlin.edu"
alias tji="talk jimb@totoro.bio.indiana.edu"
alias mroe="more"
alias moer="more"
alias email="emacs -f vm"
alias pu=pushd
alias po=popd
alias b="~/.b"
alias ds=dirs
alias ro="rm *~; rm .*~"
alias rd="rmdir"
alias ll="ls -l"
alias la="ls -a"
alias rr="rm -r"
alias md="mkdir"
alias ed2="emacs -d floss:0 -fg \"grey95\" -bg \"grey50\""

function gco
{
gcc -o $1 $1.c -g
}

successivo
–«  INDICE  »–