% Linux Guida dell'Utente                   -*- TeX -*-
% config.tex
% Copyright (c) 1993, 1994 by Larry Greenfield
%
% Traduzione di Eugenia Franzoni, 1997
%
% Questo file e' liberamente distribuibile, ma si deve preservare
% questo
% avviso di copyright su tutte le copie, e deve essere distribuito
% solo come
% parte di "Linux Guida dell'Utente". L'uso di questo file e'
% protetto dal copyright dell'intero documento, nel file 
% "copyright.tex".

% kff: What else ought I cover?  Can you think of anything?

\chapter{Voglio essere me stesso!}\label{configuration-chapter}

% \begin{quote}
% If God had known we'd need foresight, she would have given it to  us.
% \end{quote}

\section{Personalizzare {\tt bash}}

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

I file di configurazione pi\`u importanti sono quelli utilizzati dalla
shell. La shell di default di Linux \`e {\tt bash}\ttindex{bash}, ed \`e
di questa che parleremo in questo capitolo. Prima di vedere come
personalizzare {\tt bash}, bisogna sapere quali file utilizza.

\subsection{Avvio della shell}

Ci sono diversi modi in cui pu\`o essere eseguita {\tt bash}, ad
esempio come {\bf shell di login}\index{shell!di login}, che \`e come
viene eseguita al login. La shell di login dovrebbe essere la prima
che vedete.

Un'altra modalit\`a in cui si esegue {\tt bash} \`e come {\bf shell
interattiva}\index{shell!interattiva}: una shell qualsiasi che
presenti un prompt all'utente
ed aspetti dei comandi. Una shell di login \`e anche interattiva. Un
modo per ottenere una shell interattiva non di login \`e per esempio
una shell all'interno di un {\tt xterm}\ttindex{xterm}. Qualsiasi shell
che viene creata in modo diverso dal login \`e una shell non di login.

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

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

\begin{center}
\begin{tabular}{|l|l|}\hline
  \multicolumn{1}{|c|}{Tipo di shell} &
     \multicolumn{1}{c|}{Azione}\\ \hline
  Login interattivo & Viene letto ed eseguito il file 
{\tt .bash\_profile}\\ \hline
 Interattivo & Viene letto ed eseguito il file {\tt
.bashrc}\ttindex{.bashrc}\\ \hline  
 Non interattivo & Viene letto ed eseguito lo script di shell \\
\hline
\end{tabular}
\end{center}

\subsection{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 {\tt .bash\_profile}:
``{\tt source
  \verb+~+/.bashrc}''. 
Il comando
{\tt source}\ttindex{source} dice alla shell di interpretare
l'argomento come uno script di shell. Per noi questo significa che
ogni volta che viene eseguito {\tt .bash\_profile}, viene eseguito
{\em anche} {\tt .bashrc}.

Ora aggiungeremo semplicemente dei comandi al file {\tt .bashrc}. Se
volete che un comando sia valido solo per una shell di login,
aggiungetelo a {\tt .bash\_profile}.

\subsection{Aliasing}\label{aliasing-section}

Quali sono le cose che volete personalizzare? Ecco qualcosa che credo
si trovi nel {\tt .bashrc} del 90\% degli utenti di {\tt bash}:

\begin{screen}\begin{verbatim}
alias ll="ls -l"
\end{verbatim}\end{screen}

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

Alcuni alias di esempio sono riportati in 
Figura~\ref{sample-aliases}. Li potete aggiungere al vostro
{\tt .bashrc}. Un alias particolarmente interessante \`e il primo; con
quell'alias, quando qualcuno digita {\tt ls}, automaticamente viene
aggiunta l'opzione {\tt -F} (l'alias non prova ad espandersi di
nuovo). \`E un modo abbastanza comune per aggiungere delle opzioni
che usate ogni volta che richiamate un programma.

Notate i commenti con il carattere {\tt \#} nella 
Figura~\ref{sample-aliases}. Quando appare un {\tt \#}, la shell
ignora il resto della linea.\index{shell!commenti}

\begin{figure}\label{sample-aliases}
\begin{screen}\begin{verbatim}
alias ls="ls -F"          # da' i caratteri alla fine dell'elenco
alias ll="ls -l"          # ls speciale
alias la="ls -a"
alias ro="rm *~; rm .*~"  # elimina i file di backup creati da Emacs
alias rd="rmdir"          # risparmia battute!
alias md="mkdir"
alias pu=pushd            # pushd, popd, e dirs non sono stati spiegati in questo
alias po=popd             # manuale---forse volete guardare di che si tratta
alias ds=dirs             # nella manpage di bash
# questi sono solo scorciatoie da tastiera
alias to="telnet cs.oberlin.edu"
alias ta="telnet altair.mcs.anl.gov"
alias tg="telnet wombat.gnu.ai.mit.edu"
alias tko="tpalk kold@cs.oberlin.edu"
alias tjo="talk jimb@cs.oberlin.edu"
alias mroe="more"         # per correggere!
alias moer="more"
alias email="emacs -f rmail" # il mio lettore di posta
alias ed2="emacs -d floss:0 -fg \"grey95\" -bg \"grey50\""
                          # un modo di richiamare Emacs
\end{verbatim}\end{screen}
\caption{Degli esempi di alias per {\tt bash}.}
\end{figure}        

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

Non \`e 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:

\begin{screen}\begin{verbatim}
alias rf="refrobnicate -verbose -prolix -wordy -o foo.out"
\end{verbatim}\end{screen}

Inoltre, l'alias finale ha dei caratteri strani:

\begin{screen}\begin{verbatim}
alias ed2="emacs -d floss:0 -fg \"grey95\" -bg \"grey50\""
\end{verbatim}\end{screen}

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 {\tt 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, {\tt more}. Gli alias non
interferiscono con gli argomenti passati ad un programma. Funziona lo
stesso se scrivete:

\begin{screen}\begin{verbatim}
/home/larry# mroe hurd.txt
\end{verbatim}\end{screen}

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

\subsection{Variabili d'ambiente}\label{section-env-variables}

Un'altra cosa importante che si pu\`o fare nel file {\tt .bashrc} \`e
impostare le {\bf variabili d'ambiente}\index{variabili d'ambiente}.
E che cosa sono? Prendiamola da un'altra direzione: supponiamo che
stiate leggendo della documentazione per il programma {\tt pippo},
ed incontrate queste frasi:

\begin{quote}
  {\tt pippo} normalmente cerca il suo file di configurazione, {\tt .pipporc},
  nella home directory dell'utente. Comunque, se la
  variabile d'ambiente {\tt PIPPOPATH} \`e impostata ad un nome di file
  diverso, cercher\`a l\`{\i}.
\end{quote}

Ogni programma viene eseguito in un {\bf ambiente}\index{ambiente}
definito dalla shell che ha chiamato il programma\footnote{Ecco
perch\'e le shell sono cos\`{\i} importanti. Pensate se aveste dovuto
passare l'intero ambiente a mano ogni volta che aveste richiamato un
programma!}. Si pu\`o 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 {\tt PIPPOPATH}; se la
variabile non \`e definita, user\`a semplicemente il file {\tt .pipporc}
nella home directory. Se \`e definita, comunque, {\tt pippo} user\`a il
valore della variabile (che dovrebbe essere il nome di un file che
{\tt pippo} pu\`o usare) al posto del default {\tt .frugglerc}.

Ecco come si pu\`o cambiare l'ambiente in {\tt bash}\ttindex{bash}:

\begin{screen}\begin{verbatim}
/home/larry# export PGPPATH=/home/larry/secrets/pgp
\end{verbatim}\end{screen}

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

Questa particolare variabile viene usata dal famoso programma di
criptazione a chiave pubblica di Phil Zimmerman\index{Zimmerman,
Paul} {\tt pgp}\ttindex{pgp}. Normalmente {\tt 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 \`e in funzione. Impostando la variabile {\tt PGPPATH}
a questo valore, gli ho detto di usare la directory {\tt
/home/larry/secrets/pgp}. Ho dovuto leggere il manuale di {\tt pgp}
per trovare il nome esatto della variabile e che cosa fa, ma \`e
abbastanza standard l'uso del nome del programma in lettere
maiuscole, seguito dal suffisso ``PATH''.

\`E anche utile saper chiedere informazioni sull'ambiente:

\begin{screen}\begin{verbatim}
/home/larry# echo $PGPPATH
/home/larry/.pgp
/home/larry#
\end{verbatim}\end{screen}

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, {\tt echo}
avrebbe semplicemente stampato i suoi argomenti:

\begin{screen}
   \begin{verbatim}
/home/larry# echo PGPPATH
PGPPATH
/home/larry#
   \end{verbatim}
\end{screen}

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

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

Alcune di queste variabili sono piuttosto utili, quindi le
descriveremo pi\`u dettagliatamente. Guardate la
Figura~\ref{env-variables}. Queste quattro variabili sono definite
automaticamente quando fate login: non c'\`e bisogno di impostarle nei
file {\tt .bashrc} o {\tt .bash\_login}.

\begin{figure}\label{env-variables}
\begin{center}
\begin{tabular}{|l|l|l|}\hline
  \multicolumn{1}{|c|}{Variabile} &
    \multicolumn{1}{c|}{Contiene} &
    \multicolumn{1}{c|}{Esempio}\\ \hline
  {\tt HOME} & La home directory & {\tt /home/larry} \\ \hline
  {\tt TERM} & Il tipo di terminale & {\tt xterm}, {\tt vt100}, o
{\tt
    console} \\ \hline
  {\tt SHELL} & Il percorso per la shell  & {\tt /bin/bash} \\
\hline
  {\tt USER} & Il vostro nome di login & {\tt larry} \\ \hline
  {\tt PATH} & Lista di directory & {\tt
/bin:/usr/bin:/usr/local/bin:/usr/bin/X11}\\
  &             in cui cercare i programmi &
        \\ \hline
\end{tabular}
\end{center}
\caption{Alcune importanti variabili d'ambiente.}
\end{figure}

Diamo un'occhiata pi\`u da vicino alla variabile {\tt
TERM}\index{terminali}. 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 \`e stata {\tt
/etc/termcap}\ttindex{/etc/termcap}.  {\tt /etc/termcap} \`e 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 {\tt /etc/termcap} invece di
ricompilare tutto \unix. Talvolta \`e ancora pi\`u facile: lungo la
strada, il vt100\index{vt100} della Digital Equipment
Corporation\index{Digital Equipment Corporation} \`e diventato quasi
uno standard, e molti terminali nuovi sono stati costruiti in modo da
poterlo emulare, o da potersi comportare come un vt100.

Sotto \linux, il valore di {\tt TERM} \`e talvolta {\tt console}, che \`e
un terminale di tipo vt100 con delle caratteristiche aggiunte.

\bindex{shell!PATH}
Anche un'altra variabile, {\tt PATH}, \`e cruciale per il
funzionamento corretto della shell. Ecco la mia:

\begin{screen}\begin{verbatim}
/home/larry# env | grep ^PATH
PATH=/home/larry/bin:/bin:/usr/bin:/usr/local/bin:/usr/bin/X11:/usr/TeX/bin
/home/larry#
\end{verbatim}\end{screen}

Il vostro {\tt PATH} \`e 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 {\tt ls} e premo \key{Invio}, per esempio, {\tt bash} guarda per
prima cosa in {\tt /home/larry/bin}, una directory che ho creato per
i programmi scritti da me; ma io non ho creato {\tt ls} (in effetti,
credo che sia stato scritto prima che io nascessi!). Non trovandolo
in {\tt /home/larry/bin}, {\tt bash} cerca in {\tt /bin}---e l\`{\i} lo trova.
{\tt /bin/ls} esiste ed \`e eseguibile, quindi {\tt bash} interrompe la
ricerca e avvia il programma. Ci poteva essere un altro programma con
nome {\tt ls} nella directory {\tt /usr/bin}, ma {\tt bash} non l'avrebbe
mai avviato a meno che io non avessi specificato esplicitamente il
percorso:

\begin{screen}\begin{verbatim}
/home/larry# /usr/bin/ls
\end{verbatim}\end{screen}

Lo scopo della variabile {\tt  PATH} \`e di non farci digitare i
percorsi completi ogni volta che dobbiamo dare un comando. Quando
digitate un comando, {\tt bash} lo cerca nelle directory elencate in {\tt
PATH}, in ordine, e se lo trova lo avvia. Se non lo trova, vi d\`a un
errore:

\begin{screen}\begin{verbatim}
/home/larry# clubly
clubly: command not found
\end{verbatim}\end{screen}

Notate che nel mio {\tt PATH} non c'\`e la directory corrente,
``{\tt .}''. Se ci fosse stata, sarebbe stato cos\`{\i}: 

\begin{screen}\begin{verbatim}
/home/larry# echo $PATH
.:/home/larry/bin:/bin:/usr/bin:/usr/local/bin:/usr/bin/X11:/usr/TeX/bin
/home/larry#
\end{verbatim}\end{screen}

Questo \`e un problema su cui si dibatte nei circoli Unix (di cui siete
membri adesso, che vi piaccia o no). Il problema \`e che avere la
directory corrente nel percorso pu\`o essere un buco di sicurezza.
Supponiamo che facciate {\tt cd} in una directory in cui qualcuno
abbia lasciato un programma ``Trojan Horse'' con nome {\tt ls}, voi
fate un {\tt ls}, come sarebbe naturale entrando un una nuova
directory. Dato che la directory corrente, ``{\tt .}'', \`e la prima
del vostro {\tt PATH}, la shell troverebbe questa versione di {\tt
ls} e la eseguirebbe. Qualsiasi cattiveria ci fosse in quel
programma, l'avreste appena eseguita (e pu\`o 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'' {\tt ls}. Potrebbe essere anche la loro home directory,
se avessero saputo che ci sareste capitati dentro.

Sul vostro sistema \`e 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\`a), ci possono essere 
programmatori poco amichevoli che non avete mai incontrato. Se volete
o no che nel vostro percorso ci sia ``{\tt .}'' dipende dalla situazione;
non sar\`o dogmatico sull'una o sull'altra scelta, ma vorrei che aveste
presenti i rischi\footnote{Ricordatevi che potete sempre eseguire i
programmi nella directory corrente dandogli il percorso esplicito,
come ``{\tt ./foo}''\,.}. I sistemi multi-utente sono come delle
comunit\`a, dove c'\`e gente che si pu\`o comportare in modo imprevedibile.

Il mio {\tt PATH} \`e in realt\`a impostato in un modo che riassume la
maggior parte delle cose che avete imparato finora sulle variabili
d'ambiente. Ecco cosa c'\`e nel mio {\tt .bashrc}:

\begin{screen}\begin{verbatim}
export PATH=${PATH}:.:${HOME}/bin:/bin:/usr/bin:/usr/local/bin:/usr/bin/X11:/usr/TeX/bin
\end{verbatim}\end{screen}

\eindex{shell!PATH}
Qui mi avvantaggio del fatto che la variabile {\tt HOME} viene
impostata prima che {\tt bash} legga il file {\tt .bashrc}, ed uso il suo
valore nell'impostazione del {\tt PATH}. Le parentesi graffe (``{\tt
\{\ldots\}}'') 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 ``{\tt
/bin}''). Ecco un altro esempio del loro effetto:

\begin{screen}\begin{verbatim}
/home/larry# echo ${HOME}foo
/home/larryfoo
/home/larry#
\end{verbatim}\end{screen}

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

\begin{screen}\begin{verbatim}
/home/larry# echo $HOMEfoo

/home/larry#
\end{verbatim}\end{screen}

Fatemi chiarire un'altra cosa sulla mia impostazione della variabile: 
il significato di
``{\tt \${PATH}}'': quello che fa \`e includere il valore di qualsiasi
variable {\tt PATH} impostata {\em precedentemente}. Dove sarebbe
impostata una variabile del genere? Il file {\tt /etc/profile} fa da
{\tt .bash\_profile} globale, comune a tutti gli utenti; avere un
file centralizzato del genere aiuta il sistemista ad aggiungere nuove
directory al {\tt 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 {\bf PS1}. Personalmente preferisco
un prompt che mi faccia vedere il percorso della directory
corrente---ecco come faccio:

\begin{screen}\begin{verbatim}
export PS1='$PWD# '
\end{verbatim}\end{screen}

\bindex{shell!valutazione di espressioni}
Come potete vedere, qui vengono usate {\em due\/} variabili. Quella che
viene impostata \`e la variabile {\tt PS1}, e viene impostata al valore
della variabile {\tt PWD}, che pu\`o significare sia ``Print Working
Directory'' sia ``Path to Working Directory''. La valutazione di {\tt
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 {\tt PWD}. Se aveste fatto solo {\tt export~PS1=\$PWD}, 
il prompt avrebbe contenuto sempre il percorso alla directory
corrente {\em al momento in cui avevate impostato} {\tt PS1}, invece
di aggiornarlo continuamente quando si cambia directory. Beh, \`e un
po' confuso, e non \`e poi cos\`{\i} importante. Tenete solo a mente  che se
volete che nel prompt sia mostrata la directory corrente vi servono
gli apici.

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

Nell'ultimo esempio ho usato un {\em 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 \`e 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 {\tt echo `ls`} o {\tt wc `ls`}. A mano a mano che
acquistate esperienza nell'uso della shell, questa tecnica diventa
sempre pi\`u potente.

\eindex{shell!valutazione di espressioni}

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

\begin{screen}\begin{verbatim}
# 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
}
\end{verbatim}\end{screen}

% $ <- per confondere l'evidenziazione di Emacs

% **** ecco qui

\section{I file di inizializzazione di X Windows}

\xwarn La maggior parte delle persone lavorano all'interno di un
ambiente grafico, e, per le macchine \unix, questo di solito
significa usare X. Se siete abituati al Macintosh\index{Macintosh}, o
a Microsoft Windows\index{Microsoft Windows}, pu\`o essere un po' lungo
abituarcisi, specialmente per quanto riguarda la personalizzazione.

In Macintosh o in Microsoft Windows l'ambiente si personalizza
dall'{\em interno\/} dell'ambiente stesso: se volete cambiare lo
sfondo, ad esempio, si clicca su un nuovo colore in qualche programma
speciale per le impostazioni grafiche. In X, i default di sistema
vengono controllati da file di testo, che si modificano
direttamente---in altre parole, per cambiare il colore di sfondo si
scrive il nome del colore in un file.

Non si pu\`o dire che questo metodo sia pi\`u elegante di qualche sistema
a finestre commerciale. Credo che questa tendenza a rimanere legati
al testo, anche in un ambiente grafico, sia legata al fatto che X \`e
stata creata da dei programmatori che non cercavano di scrivere del
software che potesse essere usato dai loro nonni. Questa tendenza
dovrebbe cambiare nelle prossime versioni di X (almeno lo spero), ma
per adesso dovete imparare a combattere con altri file di testo; in ogni caso questo vi d\`a un controllo molto flessibile e preciso
sulla configurazione del sistema.

Ecco i file pi\`u importanti per configurare X:

\begin{samepage}
\begin{tabular}{ll}
{\bf {\tt .xinitrc}}    & Uno script usato da X all'avvio. \\
{\bf {\tt .twmrc}}      & Letto da un manager di finestre, {\tt twm}\ttindex{twm}. \\
{\bf {\tt .fvwmrc}}     & Letto da un manager di finestre, {\tt fvwm}\ttindex{fvwm}. \\
\end{tabular}
\end{samepage}
        
Tutti questi file, se esistono, dovrebbero essere nella vostra home
directory.

Il file {\tt .xinitrc} \`e un semplice script di shell che viene
avviato quando richiamate X. Pu\`o fare tutto quello che fa un normale
script di shell, ma naturalmente ha senso se si usa per avviare dei
programmi di X e per impostare dei parametri del sistema a finestre.
L'ultimo comando del file {\tt .xinitrc} \`e di solito il nome di un
manager di finestre, ad esempio {\tt /usr/bin/X11/twm}.

Che tipo di cose si mettono in un file {\tt .xinitrc}? Forse delle
chiamate al programma {\tt xsetroot}, per impostare l'aspetto della
finestra di root (lo sfondo) e del cursore del mouse, una chiamata a
{\tt xmodmap}, che dice al server\footnote{Il ``server'' \`e
semplicemente il processo X principale sulla vostra macchina, quello
con cui tutti i programmi di X devono comunicare per usare lo
schermo. Questi altri programmi si chiamano ``client'', e l'insieme
si chiama sistema ``client-server''.} come interpretare i segnali da
tastiera, e tutti gli altri programmi che volete avviare ogni volta
che avviate X (ad esempio, {\tt xclock}).

Ecco una parte del mio {\tt .xinitrc}; il vostro sar\`a quasi
sicuramente diverso, quindi questo \`e solo un esempio:

\begin{screen}\begin{verbatim}
#!/bin/sh
# La prima linea dice al sistema operativo quale shell usare per
# interpretare lo script. Lo script stesso dovrebbe essere reso eseguibile:
# lo si puo' fare con "chmod +x ~/.xinitrc".

# xmodmap e' un programma per dire al server X come interpretare i segnali
# da tastiera. Vale *veramente* la pena imparare ad usarlo. Si puo' fare
# "man xmodmap", "xmodmap -help", "xmodmap -grammar", e cosi' via. 
# Non garantisco che le espressioni qui sotto significhino qualcosa sul
# vostro sistema (non garantisco nemmeno che significhino qualcosa sul
# mio):
xmodmap -e 'clear Lock'
xmodmap -e 'keycode 176 = Control_R'
xmodmap -e 'add control = Control_R'
xmodmap -e 'clear Mod2'
xmodmap -e 'add Mod1 = Alt_L Alt_R'

# xset e' un programma per impostare qualche altro parametro del server X:
xset m 3 2 &       # parametri del mouse
xset s 600 5 &     # preferenze del salvaschermo 
xset s noblank &   # come sopra
xset fp+ /home/larry/x/fonts # per cxterm
# Per scoprirne di piu', "xset -help".

# Dice al server X di sovrapporre fish.cursor su fish.mask, ed usare 
# il disegno risultante come cursore per il mouse:
xsetroot -cursor /home/lab/larry/x/fish.cursor /home/lab/larry/x/fish.mask &

# un colore e un'immagine di sfondo che mi piacciono
xsetroot -bitmap /home/lab/larry/x/pyramid.xbm -bg tan

# da fare: xrdb? E il file .Xdefaults?

# Dovreste fare "man xsetroot" o "xsetroot -help" per avere altre
# informazioni sul programma usato qui sopra.

# Un programma client, l'orologio tondo a colori di Jim Blandy:
/usr/local/bin/circles &

# Forse vorrete avere un orologio sullo schermo in ogni momento? 
/usr/bin/X11/xclock -digital &

# Permette ai programmi client di X che girano su occs.cs.oberlin.edu di
# usare questo come schermo, e lo stesso per juju.mcs.anl.gov:
xhost occs.cs.oberlin.edu
xhost juju.mcs.anl.gov

# Potete anche dire al server X di permettere a client che girano su
# qualsiasi host (in cui host e' una macchina remota) di usare lo schermo, 
# mae'e un buco di sicurezza---questi client possono essere manovrati da
# qualcun altro, e chiunque potrebbe vedere le digitazioni della vostra
# password o cose del genere!
# In ogni caso, se volete farlo lo stesso, potete usare un "+" per
# significare tutti i possibili host, invece di uno specifico, cosi':
# xhost +

# E, infine, il manager di finestre:
/usr/bin/X11/twm
# Alcuni preferiscono altri manager. Io uso twm, ma spesso con Linux 
# viene distribuito anche fvwm:
# /usr/bin/X11/fvwm
\end{verbatim}\end{screen}

%        [Larry, or someone, does it matter if the window manager is
%started in the background or not?  It seems to work fine either way;
%I'm wondering if there's any point recommending an ``\&'' or not.
%-Karl] I believe we want it without an ``&'' so the server exits
% at the same time as the window manager

Notate che alcuni comandi vengono avviati in background (cio\`e sono seguiti
da una ``\&'') e altri no. La distinzione \`e che alcuni programmi vengono
avviati quando avviate X e continuano a funzionare finch\'e non
uscite---mettete questi in background. Altri programmi vengono eseguiti
una sola volta e se ne esce immediatamente. {\tt xsetroot} \`e uno di
questi; imposta semplicemente la finestra di root o il cursore o
qualcos'altro, e poi esce.

Una volta partito, il manager delle finestre legger\`a il suo file di
inizializzazione, che controlla cose come l'impostazione dei men\`u, o in
quale posizione vengono aperte le finestre, il controllo delle icone e
altre cose estremamente importanti. Se usate {\tt twm}, il file \`e {\tt
.twmrc}, nella vostra home directory. Se usate {\t fvwm} sar\`a {\tt
.fvwmrc} e cos\`{\i} via. Qui tratter\`o solo questi due, dato che sono quelli
che incontrerete pi\`u facilmente con Linux.

\subsection{Configurazione di Twm}\label{twm-config-section}

\bttindex{twm}
Il file {\tt .twmrc} non \`e uno script di shell---credetelo o no, \`e
scritto in un linguaggio fatto proprio per {\tt twm}!\footnote{Questa
\`e una delle caratteristiche negative dei file di inizializzazione:
hanno generalmente il loro proprio linguaggio caratteristico; ci\`o
significa che gli utenti diventano bravissimi ad imparare velocemente
i linguaggi. Suppongo che sarebbe bello se i primi programmatori di
Unix si fossero messi d'accordo su un formato standard per i file di
inizializzazione, in modo che non dovessimo imparare nuove sintassi
ogni volta, ma ad essere realisti \`e difficile predire di quali
informazioni avranno bisogno i programmi.} 
La cosa con cui la gente ama giocherellare nel file {\tt .twmrc} \`e lo
stile delle finestre (i colori e cose di questo genere), e i men\`u,
quindi ecco un file {\tt .twmrc} di esempio che configura queste
caratteristiche:

\begin{screen}
    \begin{verbatim}
# Imposta i colori per le varie parti delle finestre. Fa molto
# effetto sulla personalizzazione dell'ambiente.
Color
{
    BorderColor "OrangeRed"
    BorderTileForeground "Black"
    BorderTileBackground "Black"
    TitleForeground "black"
    TitleBackground "gold"
    MenuForeground "black"
    MenuBackground "LightGrey"
    MenuTitleForeground "LightGrey"
    MenuTitleBackground "LightSlateGrey"
    MenuShadowColor "black"
    IconForeground "DimGray"
    IconBackground "Gold"
    IconBorderColor "OrangeRed"
    IconManagerForeground "black"
    IconManagerBackground "honeydew"
}

# Spero che non abbiate un sistema in bianco e nero, ma se e' cosi'...
Monochrome
{
    BorderColor "black"
    BorderTileForeground "black"
    BorderTileBackground "white"
    TitleForeground "black"
    TitleBackground "white"
}

# Ho creato beifnag.bmp con il programma "bitmap". Qui dico a twm di
# usarlo come disegno di default per le barre del titolo delle
# finestre.
Pixmaps
{
    TitleHighlight "/home/larry/x/beifang.bmp"
}

# Non vi preoccupate di queste cose, sono solo per i fissati :-)
BorderWidth     2
TitleFont       "-adobe-new century schoolbook-bold-r-normal--14-140-75-75-p-87-iso8859-1"
MenuFont        "6x13"
IconFont        "lucidasans-italic-14"
ResizeFont      "fixed"
Zoom 50
RandomPlacement

# Questi programmi non avranno una barra del titolo per default:
NoTitle
{
  "stamp"
  "xload"
  "xclock"
  "xlogo"
  "xbiff"
  "xeyes"
  "oclock"
  "xoid"
}

# "AutoRaise" significa che la finestra viene messa in primo piano 
# ogni volta che il puntatore del mouse ci passa sopra. Io lo trovo
# scomodo, quindi l'ho disabilitato. Come potete vedere, ho ereditato
# il mio file .twmrc da persone che avevano la mia stessa idea.
AutoRaise 
{
  "nothing"    # Non mi piace autoraise # A me neanche # Nemmeno a me
}

# Qui vengono definite le funzioni dei pulsanti del mouse. Notate
# lo schema: un pulsante premuto sulla finestra di sfondo, senza
# premerci insieme nessun tasto modificatore, apre sempre un menu'. 
# Premere un pulsante su altre zone porta ad una qualche 
# manipolazione della finestra, ed i tasti modificatori vengono
# usati insieme ai pulsanti del mouse per avere le manipolazioni piu'
# sofisticate.
#
# Non c'e' bisogno che seguiate questo schema nel vostro .twmrc --
# la configurazione dell'ambiente e' completamente a vostro piacere.

# Pulsante = TASTI : CONTESTO : FUNZIONE
# ----------------------------------
Button1 =      : root    : f.menu "main"
Button1 =      : title   : f.raise
Button1 =      : frame   : f.raise
Button1 =      : icon    : f.iconify
Button1 = m    : window  : f.iconify

Button2 =      : root    : f.menu "stuff"
Button2 =      : icon    : f.move
Button2 = m    : window  : f.move
Button2 =      : title   : f.move
Button2 =      : frame   : f.move
Button2 = s    : frame   : f.zoom
Button2 = s    : window  : f.zoom

Button3 =      : root    : f.menu "x"
Button3 =      : title   : f.lower
Button3 =      : frame   : f.lower
Button3 =      : icon    : f.raiselower

# Potete scrivere delle funzioni personalizzate; questa viene usata
# nel menu' "windowops" quasi alla fine di questo file:
Function "raise-n-focus"
{
    f.raise
    f.focus
}

# Okay, qui sotto ci sono i menu' a cui ci si riferisce nella sezione
# dei pulsanti del mouse. Notate che molte delle voci 
# richiamano a loro volta dei sottomenu'. Potete avere quanti livelli
# di menu' volete, ma state attenti a non farli ricorsivi: non
# funzionano, ci ho provato.

menu "main"
{
"Vanilla"       f.title
"Emacs"         f.menu "emacs"
"Logins"        f.menu "logins"
"Xlock"         f.menu "xlock"
"Misc"          f.menu "misc"
}

# Questo mi permette di invocare Emacs su macchine diverse. Date 
# un'occhiata alla sezione sui file .rhosts per altre informazioni
# su come fare:
menu "emacs"
{
"Emacs"      f.title
"here"       !"/usr/bin/emacs &"
""           f.nop
"phylo"      !"rsh phylo \"emacs -d floss:0\" &"
"geta"       !"rsh geta \"emacs -d floss:0\" &"
"darwin"     !"rsh darwin \"emacs -d floss:0\" &"
"ninja"      !"rsh ninja \"emacs -d floss:0\" &"
"indy"       !"rsh indy \"emacs -d floss:0\" &"
"oberlin"    !"rsh cs.oberlin.edu \"emacs -d floss.life.uiuc.edu:0\" &"
"gnu"        !"rsh gate-1.gnu.ai.mit.edu \"emacs -d floss.life.uiuc.edu:0\" &"
}

# Mi fa aprire degli xterm su parecchie altre macchine. Guardate la
# sezione sui file .rhosts per altre informazioni.
menu "logins"
{
"Logins"     f.title
"here"       !"/usr/bin/X11/xterm -ls -T `hostname` -n `hostname` &"
"phylo"      !"rsh phylo \"xterm -ls -display floss:0 -T phylo\" &"
"geta"       !"rsh geta \"xterm -ls -display floss:0 -T geta\" &"
"darwin"     !"rsh darwin \"xterm -ls -display floss:0 -T darwin\" &"
"ninja"      !"rsh ninja \"xterm -ls -display floss:0 -T ninja\" &"
"indy"       !"rsh indy \"xterm -ls -display floss:0 -T indy\" &"
}

# I salvaschermo di xlock, richiamati con varie opzioni (ognuna
# delle quali da' un'immagine diversa):
menu "xlock"
{
"Hop"   !"xlock -mode hop &"
"Qix"   !"xlock -mode qix &"
"Flame" !"xlock -mode flame &"
"Worm" !"xlock -mode worm &"
"Swarm" !"xlock -mode swarm &"
"Hop NL"   !"xlock -mode hop -nolock &"
"Qix NL"   !"xlock -mode qix -nolock &"
"Flame NL" !"xlock -mode flame -nolock &"
"Worm NL" !"xlock -mode worm -nolock &"
"Swarm NL" !"xlock -mode swarm -nolock &"
}

# Programmi vari che uso ogni tanto:
menu "misc"
{
"Xload"         !"/usr/bin/X11/xload &"
"XV"            !"/usr/bin/X11/xv &"
"Bitmap"        !"/usr/bin/X11/bitmap &"
"Tetris"        !"/usr/bin/X11/xtetris &"
"Hextris"       !"/usr/bin/X11/xhextris &"
"XRoach"        !"/usr/bin/X11/xroach &"
"Analog Clock"  !"/usr/bin/X11/xclock -analog &"
"Digital Clock" !"/usr/bin/X11/xclock -digital &"
}

# Questo e' il menu' che ho collegato al pulsante centrale del mouse:
menu "stuff"
{
"Chores"       f.title
"Sync"         !"/bin/sync"
"Who"          !"who | xmessage -file - -columns 80 -lines 24 &"
"Xhost +"      !"/usr/bin/X11/xhost + &"
"Rootclear"    !"/home/larry/bin/rootclear &"
}

# Funzioni di X che talvolta sono comode:
menu "x"
{
"X Stuff"               f.title
"Xhost +"               !"xhost + &"
"Refresh"               f.refresh
"Source .twmrc"         f.twmrc
"(De)Iconify"           f.iconify
"Move Window"           f.move
"Resize Window"         f.resize
"Destroy Window"        f.destroy
"Window Ops"            f.menu "windowops"
""                      f.nop
"Kill twm"              f.quit
}

# Un sottomenu' del precedente:
menu "windowops"
{
"Window Ops"            f.title
"Show Icon Mgr"         f.showiconmgr
"Hide Icon Mgr"         f.hideiconmgr
"Refresh"               f.refresh
"Refresh Window"        f.winrefresh
"twm version"           f.version
"Focus on Root"         f.unfocus
"Source .twmrc"         f.twmrc
"Cut File"              f.cutfile
"(De)Iconify"           f.iconify
"DeIconify"             f.deiconify
"Move Window"           f.move
"ForceMove Window"      f.forcemove
"Resize Window"         f.resize
"Raise Window"          f.raise
"Lower Window"          f.lower
"Raise or Lower"        f.raiselower
"Focus on Window"       f.focus
"Raise-n-Focus"         f.function "raise-n-focus"
"Destroy Window"        f.destroy
"Kill twm"              f.quit
}
    \end{verbatim}
\end{screen}

Phew! Credetemi, non \`e nemmeno il file .twmrc pi\`u complicato che
abbia mai visto. Probabilmente avrete un esempio decente di {\tt
.twmrc} con la vostra versione di X. Guardate nella directory 
{\tt /usr/lib/X11/twm/} o in  {\tt /usr/X11/lib/X11/twm} e vedete com'\`e.

Un bug a cui bisogna fare attenzione in {\tt .twmrc} \`e scordarsi di 
mettere l'\& dopo un comando da men\`u. Se notate che X si congela
quando gli date determinati comandi, \`e probabile che sia questa la
causa. Uscite da X con 
\key{Control}-\key{Alt}-\key{Backspace}, modificate {\tt .twmrc} e
riprovate.
\ettindex{twm}

\subsection{Configurazione di Fvwm}\label{fvwm-config-section}
\bttindex{fvwm}

Se state usando {\tt fvwm} ci sono dei buoni file di esempio nella
directory {\tt /usr/lib/X11/fvwm/} (o {\tt /usr/X11/lib/X11/fvwm/}).

[Gente: non so niente di fvwm, anche se credo di poter capire
qualcosa dai file di configurazione di esempio. Comunque, lo stesso
pu\`o fare il lettore :-). Inoltre, dato che esiste il file
system.twmrc nella directory menzionata, mi chiedo se vale la pena di
dare il lungo esempio di .twmrc qui sopra. Per ora ce lo lascio, ma
non so se va bene o no. -Karl]
\ettindex{fvwm}

\section{Altri file di inizializzazione}

Altri file di inizializzazione notevoli sono:

\begin{samepage}
\begin{tabular}{ll}
{\bf {\tt .emacs}}    & Letto dall'editor di testi Emacs al suo avvio. \\
{\bf {\tt .netrc}}    & D\`a i nomi di login e le password di default per ftp. \\
{\bf {\tt .rhosts}}   & Rende l'account accessibile da remoto. \\
{\bf {\tt .forward}}  & Per inoltrare automaticamente la posta. \\
\end{tabular}
\end{samepage}

\subsection{Il file di inizializzazione di Emacs}
Se usate  {\tt emacs} come editor primario, il file {\tt .emacs} \`e
piuttosto importante. Se ne tratta largamente nel Capitolo~\ref{emacs-chapter}.

\subsection{Impostazioni dell'FTP}
Il file .netrc vi permette di impostare dei default per l'{\tt ftp} prima
di avviare {\tt ftp} stesso. Ecco un piccolo esempio:

  \begin{screen}
    \begin{verbatim}
machine floss.life.uiuc.edu login larry password fishSticks
machine darwin.life.uiuc.edu login larry password fishSticks
machine geta.life.uiuc.edu login larry password fishSticks
machine phylo.life.uiuc.edu login larry password fishSticks
machine ninja.life.uiuc.edu login larry password fishSticks
machine indy.life.uiuc.edu login larry password fishSticks

machine clone.mcs.anl.gov login fogel password doorm@
machine osprey.mcs.anl.gov login fogel password doorm@
machine tern.mcs.anl.gov login fogel password doorm@
machine altair.mcs.anl.gov login fogel password doorm@
machine dalek.mcs.anl.gov login fogel password doorm@
machine juju.mcs.anl.gov login fogel password doorm@

machine sunsite.unc.edu login anonymous password larry@cs.oberlin.edu
    \end{verbatim}
  \end{screen}

Ogni linea dei file {\tt .netrc} specifica il nome della macchina, il 
nome di login da usare per default su quella macchina, e una
password. \`E molto comodo se fate molto spesso {\tt ftp} e siete
stanchi di digitare continuamente lo username e la password su
diversi siti. Se fate {\tt ftp} su una delle macchine elencate nel
file, il programma prover\`a a collegarsi automaticamente usando le
informazioni presenti nel file {\tt .netrc}.

Si pu\`o dire ad {\tt ftp} di ignorare il file .netrc e di non tentare di
fare login automaticamente richiamandolo con l'opzione {\tt -n}: ``{\tt
ftp~-n}''.

Bisogna assicurarsi che il file {\tt .netrc} sia leggibile {\em solo\/} da
voi. Usate il comando {\tt chmod} per impostare i permessi di lettura del
file. Se altri possono leggerlo, potranno scoprire le vostre password
sugli altri siti che vi sono nominati. Questo \`e una delle falle di
sicurezza pi\`u gravi che si possono avere; per incoraggiarvi ad essere
prudenti, {\tt ftp} ed altri programmi che usano il file  {\tt .netrc} si
rifiuteranno di funzionare se i permessi di lettura del file sono
impostati male.

C'\`e di pi\`u sul file {\tt .netrc} di quanto abbia detto: quando vi capita,
fate ``{\tt man~.netrc}'' o ``{\tt man~ftp}''.

\subsection{Come permettere l'accesso remoto al vostro account}

Se avete un file {\tt .rhosts} nella home directory, vi permetter\`a di far
girare remotamente programmi su questa macchina; potrete cio\`e essere
collegati alla macchina {\tt cs.oberlin.edu}, e con un file {\tt .rhosts}
ben configurato su {\tt floss.life.uiuc.edu} far girare un
programma su {\tt floss.life.uiuc.edu} e far arrivare l'output su {\tt
cs.oberlin.edu}, senza nemmeno dovervi collegare o digitare la password.

Un file {\tt .rhosts} \`e fatto cos\`{\i}:

  \begin{screen}
    \begin{verbatim}
frobnozz.cs.knowledge.edu jsmith
aphrodite.classics.hahvaahd.edu wphilps
frobbo.hoola.com trixie
    \end{verbatim}
  \end{screen}

Il formato \`e abbastanza chiaro:  il nome di una macchina, seguito dal nome
dell'utente. Supponiamo che questo esempio sia il mio file {\tt .rhosts}
su {\tt floss.life.uiuc.edu}: ci\`o significherebbe che potrei far girare
dei programmi su floss, con l'output visualizzato su una qualsiasi delle
macchine elencate, fintanto che io fossi collegato con il nome di utente
corrispondente.

Il meccanismo esatto con cui si fa girare un programma remoto \`e di solito
il programma {\tt rsh}, che sta per ``remote shell'', e quello che fa \`e
inizializzare una shell su una macchina remota ed eseguire un comando
specificato. Ad esempio:

\begin{screen}\begin{verbatim}
frobbo$ whoami
trixie
frobbo$ rsh floss.life.uiuc.edu "ls ~"
foo.txt    mbox   url.ps    snax.txt
frobbo$ rsh floss.life.uiuc.edu "more ~/snax.txt"
[snax.txt viene visualizzato qui]
\end{verbatim}\end{screen}

L'utente trixie su floss.life.uiuc.edu, che ha il file {\t .rhosts} di
esempio riportato qui sopra, permette esplicitamente a trixie su
frobbo.hoola.com di far girare programmi come trixie da floss.

Non c'\`e bisogno di avere lo stesso nome di utente su tutte le macchine per
far funzionare bene un file {\tt .rhosts}. Usate l'opzione ``{\tt -l}''
con {\tt rsh}, per dire alla macchina remota quale nome di utente usare
per fare login. Se quel nome di utente esiste sulla macchina remota, ed ha
un file {\tt .rhosts} con la macchina ed il nome di utente su cui siete
collegati, {\tt rsh} funzioner\`a. 

\begin{screen}\begin{verbatim}
frobbo$ whoami
trixie
frobbo$ rsh -l larry floss.life.uiuc.edu "ls ~"
[Elenco della mia directory su floss]
\end{verbatim}\end{screen}

Tutto questo funzioner\`a se l'utente {\tt larry} su {\tt 
floss.life.uiuc.edu} ha un file {\tt .rhosts} che permette all'utente {\tt
trixie} da  {\tt frobbo.hoopla.com} di far girare dei programmi sul suo
account. Se sono o meno la stessa persona \`e irrilevante: le uniche cose
importanti sono i nomi degli utenti, i nomi delle macchine e le voci nel
file {\tt .rhosts} di larry su floss. Notate che il file {\tt .rhosts} di
trixie su frobbo non c'entra niente, importa solo quello sulla macchina
remota.

Ci sono altre combinazioni che possono entrare in un file {\tt
.rhosts}---ad esempio, si pu\`o lasciare vuoto il nome dell'utente dopo il
nome di una macchina remota, per permettere a tutti gli utenti di
quella macchina di far girare programmi sulla macchina locale! Questo \`e,
naturalmente, un rischio per la sicurezza: qualcuno potrebbe far girare un
programma che rimuove i vostri file, solo avendo un account su una
determinata macchina. Se fate cose come lasciare bianco il nome
dell'utente, vi dovreste accertare che il file {\tt .rhosts} \`e leggibile
solo da voi.

\subsection{Forwardare la posta}
Potete anche avere un file {\tt .forward}, che non \`e strettamente parlando
un file di inizializzazione. Se contiene un indirizzo di posta
elettronica, tutta la posta che vi arriva sar\`a forwardata a
quell'indirizzo. \`E utile quando avete account su diversi sistemi, ma
volete leggere la posta solo su uno di essi.

C'\`e un mare di altri possibili file di inizializzazione. Il numero esatto
varier\`a da sistema a sistema, e dipende da quali software sono installati.
Un modo di impararne di pi\`u \`e guardare i file nella vostra home directory
il cui nome inizia per ``{\tt .}'': non sono sempre file di
inizializzazione, ma c'\`e una buona possibilit\`a. 

\section{Alcuni esempi}

% Heh heh, do you think this is a big mistake?  I'll risk it for
% now...

L'esempio pi\`u calzante che vi posso fare \`e un sistema Linux che
funziona. Quindi,
se avete accesso ad Internet, potete tranquillamente fare telnet su 
{\tt floss.life.uiuc.edu}.  Fate login come ``guest'', con password
``explorer'', e date un'occhiata in giro. La maggior parte dei file
di esempio che ho messo in questo libro si possono trovare in {\tt
/home/kfogel}, ma ci sono anche altre directory utente. Sentitevi
liberi di copiare tutto quello che riuscite a leggere. Per favore
siate prudenti: floss non \`e estremamente sicuro, e potete di certo
riuscire ad avere accesso come root, se ci provate abbastanza.
Preferisco avere fiducia, invece che vigilare costantemente, per
mantenere la sicurezza del sistema.
% Local Variables: 
% mode: latex
% TeX-master: "guide"
% End: 
