session.tex

   1  \chapter{Sessioni di lavoro e terminali}
   2 \label{cha:session}
   3
   4 Esamineremo in questo capitolo i concetti base del sistema delle sessioni di
   5 lavoro, vale a dire il metodo con cui il kernel gestisce l'accesso concorrente
   6 al sistema da parte di più utenti, permettendo loro di eseguire più programmi
   7 in contemporanea.  Nella seconda parte del capitolo tratteremo poi il
   8 funzionamento dell'I/O su terminale, e delle varie peculiarità che esso viene
   9 ad assumere a causa del suo stretto legame con le modalità di accesso al
  10 sistema da parte degli utenti.
  11
  12
  13 \section{Il \textit{job control}}
  14 \label{sec:sess_job_control}
  15
  16 Viene comunemente chiamato \textit{job control} quell'insieme di funzionalità
  17 il cui scopo è quello di permettere ad un utente di poter sfruttare le
  18 capacità multitasking di un sistema Unix per eseguire in contemporanea più
  19 processi, pur potendo accedere, di solito, ad un solo terminale,\footnote{con
  20   X e con i terminali virtuali tutto questo non è più vero, dato che si può
  21   accedere a molti terminali in contemporanea, ma il sistema è nato prima
  22   dell'esistenza di tutto ciò.} avendo cioè un solo punto in cui si può avere
  23 accesso all'input ed all'output degli stessi.
  24
  25
  26 \subsection{Una panoramica introduttiva}
  27 \label{sec:sess_job_control_overview}
  28
  29 Il \textit{job control} è una caratteristica opzionale, introdotta in BSD
  30 negli anni '80, e successivamente standardizzata da POSIX.1; la sua
  31 disponibilità nel sistema è verificabile attraverso il controllo della macro
  32 \macro{\_POSIX\_JOB\_CONTROL}. In generale il \textit{job control} richiede il
  33 supporto sia da parte della shell (quasi tutte ormai lo fanno), che da parte
  34 del kernel; in particolare il kernel deve assicurare sia la presenza di un
  35 driver per i terminali abilitato al \textit{job control} che quella dei
  36 relativi segnali illustrati in \secref{sec:sig_job_control}.
  37
  38 In un sistema che supporta il \textit{job control} una volta completato il
  39 login (che esamineremo in dettaglio in \secref{sec:sess_login}), l'utente avrà
  40 a disposizione una shell dalla quale eseguire i comandi e potrà iniziare
  41 quella che viene chiamata una \textsl{sessione}, che riunisce (vedi
  42 \secref{sec:sess_proc_group}) tutti i processi eseguiti all'interno dello
  43 stesso login.
  44
  45 Siccome la shell è collegata ad un solo terminale (che viene usualmente
  46 chiamato \textsl{terminale di controllo}) un solo comando alla volta (quello
  47 che viene detto in \textit{foreground}), potrà scrivere e leggere dal
  48 terminale. La shell però può eseguire anche più comandi in contemporanea,
  49 mandandoli in \textit{background} (aggiungendo una \cmd{\&} alla fine del
  50 comando), nel qual caso essi saranno eseguiti senza essere collegati al
  51 terminale.
  52
  53 Si noti come si sia parlato di comandi e non di programmi o processi; fra le
  54 funzionalità della shell infatti c'è anche quella di consentire di concatenare
  55 più programmi in una sola riga di comando con le pipe, ed in tal caso verranno
  56 eseguiti più programmi, inoltre, anche quando si invoca un singolo programma,
  57 questo potrà sempre lanciare sottoprocessi per eseguire dei compiti specifici.
  58
  59 Per questo l'esecuzione di un comando può originare più di un processo; quindi
  60 nella gestione del job control non si può far riferimento ai singoli processi.
  61 Per questo il kernel prevede la possibilità di raggruppare più processi in un
  62 \textit{process group} (detto anche \textsl{raggruppamento}, vedi
  63 \secref{sec:sess_proc_group}) e la shell farà sì che tutti i processi che
  64 originano da una riga di comando appartengano allo stesso \textit{process
  65   group}, in modo che le varie funzioni di controllo, ed i segnali inviati dal
  66 terminale, possano fare riferimento ad esso.
  67
  68 In generale allora all'interno di una sessione avremo un eventuale (possono
  69 non esserci) \textit{process group} in \textit{foreground}, che riunisce i
  70 processi che possono accedere al terminale, e più \textit{process group} in
  71 \textit{background}, che non possono accedervi. Il job control prevede che
  72 quando un processo appartenente ad un raggruppamento in \textit{background}
  73 cerca di accedere al terminale questo invii a tutti i processi del
  74 raggruppamento un segnale di \macro{SIGTTIN} o di \macro{SIGTTOU}, a seconda
  75 che l'accesso sia rispettivamente in lettura o scrittura, bloccando (secondo
  76 il comportamento di default esposto in \secref{sec:sig_job_control}) i
  77 processi.
  78
  79 Un comportamento analogo si ha anche per i segnali generati dai comandi di
  80 tastiera inviati dal terminale con \cmd{C-z}, \cmd{C-c}, \cmd{C-y} e
  81 \verb|C-\|; questi generano rispettivamente i segnali \macro{SIGTSTP},
  82 \macro{SIGINT}, \macro{SIGQUIT} e \macro{SIGTERM}, che vengono inviati a tutti
  83 i processi del raggruppamento in \textit{foreground}. In particolare il primo
  84 di essi, \macro{SIGTSTP}, interrompe l'esecuzione del comando, che può poi
  85 essere mandato in \textit{background} con il comando \cmd{bg}. Il comando
  86 \cmd{fg} consente invece di mettere in \textit{foreground} un comando
  87 precedentemente lanciato in \textit{background}.
  88
  89 Di norma la shell si cura anche di notificare all'utente (di solito prima
  90 della stampa a video del prompt) lo stato dei vari processi, essa infatti usa
  91 le caratteristiche della funzione \func{waitpid} (si riveda quanto detto in
  92 \secref{sec:proc_wait}) per verificare quali gruppi di processi sono bloccati
  93 e quali sono terminati.
  94
  95
  96 \subsection{I \textit{process group} e le \textsl{sessioni}}
  97 \label{sec:sess_proc_group}
  98
  99 Come accennato in \secref{sec:sess_job_control_overview} nel job control i
 100 processi vengono raggruppati in \textit{process group} e \textit{sessioni};
 101 per far questo vengono utilizzati due ulteriori identificatori (oltre quelli
 102 visti in \secref{sec:proc_pid}) che il kernel associa a ciascun processo:
 103 l'identificatore del \textit{process group} e l'identificatore della
 104 \textsl{sessione}, che vengono indicati rispettivamente con le sigle
 105 \acr{pgid} e \acr{sid}, e sono mantenuti in variabili di tipo \type{pid\_t}. I
 106 valori di questi identificatori possono essere visualizzati dal comando
 107 \cmd{ps} usando l'opzione \cmd{-j}.
 108
 109 Un \textit{process group} è pertanto definito da tutti i processi che hanno lo
 110 stesso \acr{pgid}; è possibile leggere il valore di questo identificatore con
 111 le funzioni \func{getpgid} e \func{getpgrp},\footnote{\func{getpgrp} è
 112   definita nello standard POSIX.1, mentre \func{getpgid} è richiesta da SVr4.}
 113 i cui prototipi sono:
 114 \begin{functions}
 115   \headdecl{unistd.h}
 116
 117   \funcdecl{pid\_t getpgid(pid\_t pid)}
 118   Legge il \acr{pgid} del processo \param{pid}.
 119
 120   \funcdecl{pid\_t getpgrp(void)}
 121   Legge il \acr{pgid} del processo corrente.
 122
 123   \bodydesc{Le funzioni restituiscono il \acr{pgid} del processo,
 124     \func{getpgrp} ha sempre successo, mentre \func{getpgid} restituisce -1
 125     ponendo \var{errno} a \macro{ESRCH} se il processo selezionato non esiste.}
 126 \end{functions}
 127
 128 La funzione \func{getpgid} permette di specificare il \acr{pid} del processo
 129 di cui si vuole sapere il \acr{pgid}; un valore nullo per \param{pid}
 130 restituisce il \acr{pgid} del processo corrente; \func{getpgrp} è di norma
 131 equivalente a \code{getpgid(0)}.
 132
 133 In maniera analoga l'identificatore della sessione può essere letto dalla
 134 funzione \func{getsid}, che però nelle \acr{glibc}\footnote{la system call è
 135   stata introdotta in Linux a partire dalla versione 1.3.44, il supporto nelle
 136   librerie del C è iniziato dalla versione 5.2.19. La funzione non è prevista
 137   da POSIX.1, che parla solo di processi leader di sessione, e non di
 138   identificatori di sessione.} è accessibile solo definendo
 139 \macro{\_XOPEN\_SOURCE} e \macro{\_XOPEN\_SOURCE\_EXTENDED}; il suo prototipo
 140 è:
 141 \begin{prototype}{unistd.h}{pid\_t getsid(pid\_t pid)}
 142   Legge l'identificatore di sessione del processo \param{pid}.
 143
 144   \bodydesc{La funzione restituisce l'identificatore (un numero positivo) in
 145   caso di successo, e -1 in caso di errore, nel qual caso \var{errno} assumerà
 146   i valori:
 147     \begin{errlist}
 148     \item[\macro{ESRCH}] Il processo selezionato non esiste.
 149     \item[\macro{EPERM}] In alcune implementazioni viene restituito quando il
 150       processo selezionato non fa parte della stessa sessione del processo
 151       corrente.
 152     \end{errlist}
 153   }
 154 \end{prototype}
 155
 156 Entrambi gli identificatori vengono inizializzati alla creazione di ciascun
 157 processo con lo stesso valore che hanno nel processo padre, per cui un
 158 processo appena creato appartiene sempre allo stesso raggruppamento e alla
 159 stessa sessione del padre. Vedremo poi come sia possibile creare più
 160 \textit{process group} all'interno della stessa sessione, e spostare i
 161 processi dall'uno all'altro, ma sempre all'interno di una stessa sessione.
 162
 163 Ciascun gruppo di processi ha sempre un processo principale, il cosiddetto
 164 \textit{process group leader}, che è identificato dall'avere un \acr{pgid}
 165 uguale al suo \acr{pid}, in genere questo è il primo processo del gruppo, che
 166 si incarica di lanciare tutti gli altri. Un nuovo gruppo si crea con la
 167 funzione \func{setpgrp},\footnote{questa è la definizione di POSIX.1, BSD
 168   definisce una funzione con lo stesso nome, che però è identica a
 169   \func{setpgid}; nelle \acr{glibc} viene sempre usata sempre questa
 170   definizione, a meno di non richiedere esplicitamente la compatibilità
 171   all'indietro con BSD, definendo la macro \macro{\_BSD\_SOURCE}.} il cui
 172 prototipo è:
 173 \begin{prototype}{unistd.h}{int setpgrp(void)}
 174   Modifica il \acr{pgid} al valore del \acr{pid} del processo corrente.
 175
 176   \bodydesc{La funzione restituisce il valore del nuovo \textit{process
 177       group}.}
 178 \end{prototype}
 179
 180 La funzione, assegnando al \acr{pgid} il valore del \acr{pid} processo
 181 corrente, rende questo \textit{process leader} di un nuovo gruppo, tutti i
 182 successivi processi da esso creati apparterranno (a meno di non cambiare di
 183 nuovo il \acr{pgid}) al nuovo gruppo. È possibile invece spostare un processo
 184 da un gruppo ad un altro con la funzione \func{setpgid}, il cui prototipo è:
 185 \begin{prototype}{unistd.h}{int setpgid(pid\_t pid, pid\_t pgid)}
 186   Assegna al \acr{pgid} del processo \param{pid} il valore \param{pgid}.
 187
 188   \bodydesc{La funzione ritorna il valore del nuovo \textit{process group}, e
 189   -1 in caso di errore, nel qual caso \var{errno} assumerà i valori:
 190     \begin{errlist}
 191     \item[\macro{ESRCH}] Il processo selezionato non esiste.
 192     \item[\macro{EPERM}] Il cambiamento non è consentito.
 193     \item[\macro{EINVAL}] Il valore di \param{pgid} è negativo.
 194     \end{errlist}
 195  }
 196 \end{prototype}
 197
 198 La funzione permette di cambiare il \acr{pgid} del processo \param{pid}, ma il
 199 cambiamento può essere effettuato solo se \param{pgid} indica un
 200 \textit{process group} che è nella stessa sessione del processo chiamante.
 201 Inoltre la funzione può essere usata soltanto sul processo corrente o su uno
 202 dei suoi figli, ed in quest'ultimo caso ha successo soltanto se questo non ha
 203 ancora eseguito una \func{exec}. Specificando un valore nullo per \param{pid}
 204 si indica il processo corrente, mentre specificando un valore nullo per
 205 \param{pgid} si imposta il \textit{process group} al valore del \acr{pid} del
 206 processo selezionato; pertanto \func{setpgrp} è equivalente a \code{setpgid(0,
 207   0)}.
 208
 209 Di norma questa funzione viene usata dalla shell quando si usano delle
 210 pipeline, per mettere nello stesso process group tutti i programmi lanciati su
 211 ogni linea di comando; essa viene chiamata dopo una \func{fork} sia dal
 212 processo padre, per impostare il valore nel figlio, che da quest'ultimo, per
 213 sé stesso, in modo che il cambiamento di \textit{process group} sia immediato
 214 per entrambi; una delle due chiamate sarà ridondante, ma non potendo
 215 determinare quale dei due processi viene eseguito per primo, occorre eseguirle
 216 comunque entrambe per evitare di esporsi ad una race condition.
 217
 218 Si noti come nessuna delle funzioni esaminate finora permetta di spostare un
 219 processo da una sessione ad un altra; infatti l'unico modo di far cambiare
 220 sessione ad un processo è quello di crearne una nuova con l'uso di
 221 \func{setsid}; il suo prototipo è:
 222 \begin{prototype}{unistd.h}{pid\_t setsid(void)}
 223   Crea una nuova sessione sul processo corrente settandone \acr{sid} e
 224   \acr{pgid}.
 225
 226   \bodydesc{La funzione ritorna il valore del nuovo \acr{sid}, e -1 in caso di
 227     errore, il solo errore possibile è \macro{EPERM}, che si ha quando il
 228     \acr{pgid} e \acr{pid} del processo concidono.}
 229 \end{prototype}
 230
 231 La funzione imposta il \acr{pgid} ed il \acr{sid} del processo corrente al
 232 valore del suo \acr{pid}, creando così una nuova sessione ed un nuovo
 233 \textit{process group} di cui esso diventa leader (come per i \textit{process
 234   group} un processo si dice leader di sessione se il suo \acr{sid} è uguale
 235 al suo \acr{pid}).  Inoltre il processo non avrà più un terminale di
 236 controllo.
 237
 238 La funzione ha successo soltanto se il processo non è già leader per un
 239 \textit{process group}, per cui per usarla di norma si esegue una \func{fork}
 240 e si esce, per poi chiamare \func{setsid} nel processo figlio, in modo che,
 241 avendo questo lo stesso \acr{pgid} del padre ma un \acr{pid} diverso, non ci
 242 siano possibilità di errore.  Questa funzione viene usata di solito nel
 243 processo di login (per i dettagli vedi \secref{sec:sess_login}) per
 244 raggruppare in una sessione tutti i comandi eseguiti da un utente dalla sua
 245 shell.
 246
 247
 248
 249 \subsection{Il terminale di controllo}
 250 \label{sec:sess_ctrl_term}
 251
 252 Come accennato in \secref{sec:sess_job_control_overview} ad ogni sessione di
 253 lavoro di norma viene associato un terminale di controllo. Alla creazione
 254 della sessione con \func{setsid} infatti ogni associazione con un precedente
 255 terminale di controllo viene spezzata, ed il processo dovrà riottenere (se
 256 necessario, vedi \secref{sec:sess_daemon}), un terminale di controllo.
 257
 258 Le modalità con cui
 259
 260
 261 \subsection{Dal login alla shell}
 262 \label{sec:sess_login}
 263
 264 L'organizzazione del sistema del job control è strettamente connessa alle
 265 modalità con cui un utente accede al sistema per dare comandi, collegandosi ad
 266 esso con un terminale, che sia questo realmente tale, come un VT100 collegato
 267 ad una seriale o virtuale, come quelli associati a schermo e tastiera o ad una
 268 connessione di rete. Dato che i concetti base sono gli stessi, e dato che alla
 269 fine le differenze sono\footnote{in generale nel caso di login via rete o di
 270   terminali lanciati dall'interfaccia grafica cambia anche il processo da cui
 271   ha origine l'esecuzione della shell.} nel device cui il kernel associa i
 272 file standard (vedi \secref{sec:file_std_descr}) per l'I/O, tratteremo solo il
 273 caso classico del terminale.
 274
 275 Abbiamo già brevemente illustrato in \secref{sec:intro_kern_and_sys} le
 276 modalità con cui il sistema si avvia, e di come, a partire da \cmd{init},
 277 vengano lanciati tutti gli altri processi. Adesso vedremo in maniera più
 278 dettagliata le modalità con cui il sistema arriva a fornire ad un utente la
 279 shell che gli permette di lanciare i suoi comandi su un terminale.
 280
 281 Nella maggior parte delle distribuzioni di GNU/Linux\footnote{fa eccezione la
 282   distribuzione \textit{Slackware}, come alcune distribuzioni su dischetto, ed
 283   altre distribuzioni dedicate a compiti limitati e specifici.}  viene usata
 284 la procedura di avvio di System V; questa prevede che \cmd{init} legga dal
 285 file di configurazione \file{/etc/inittab} quali programmi devono essere
 286 lanciati, ed in quali modalità, a seconda del cosiddetto \textit{run level},
 287 anch'esso definito nello stesso file.
 288
 289 Tralasciando la descrizione del sistema dei run level, (per il quale si
 290 rimanda alla lettura delle pagine di manuale di \cmd{init} e di
 291 \file{inittab}) quello che comunque viene sempre fatto è di eseguire almeno
 292 una istanza di un programma che permetta l'accesso ad un terminale. Uno schema
 293 di massima della procedura è riportato in \figref{fig:sess_term_login}.
 294
 295 \begin{figure}[htb]
 296   \centering
 297   \includegraphics[width=15cm]{img/tty_login}
 298   \caption{Schema della procedura di login su un terminale.}
 299   \label{fig:sess_term_login}
 300 \end{figure}
 301
 302 Un terminale, che esso sia un terminale effettivo, attaccato ad una seriale o
 303 ad un altro tipo di porta di comunicazione, o una delle console virtuali
 304 associate allo schermo, viene sempre visto attraverso attraverso un device
 305 driver che ne presenta un'interfaccia comune su un apposito file di
 306 dispositivo. Storicamente i primi terminali erano appunto terminali di
 307 telescriventi (\textit{teletype}), da cui deriva sia il nome dell'interfaccia,
 308 \textit{tty}, che quello dei relativi file di dispositivo, che sono sempre
 309 della forma \texttt{/dev/tty*}.\footnote{questo vale anche per i terminali
 310   vitruali associati alle connessioni di rete con \cmd{telnet} o \cmd{ssh}.}
 311
 312 Per controllare un terminale si usa di solito il programma \cmd{getty} (od una
 313 delle sue varianti), che permette di mettersi in ascolto su uno di questi
 314 dispositivi. Alla radice della catena che porta ad una shell per i comandi
 315 perciò c'è sempre \cmd{init} che esegue prima una \func{fork} e poi una
 316 \func{exec} per lanciare una istanza di questo programma su un terminale, il
 317 tutto ripetuto per ciascuno dei terminali che si hanno a disposizione (o per
 318 un certo numero di essi, nel caso delle console virtuali), secondo quanto
 319 indicato dall'amministratore nel file di configurazione del programma,
 320 \file{/etc/inittab}.
 321
 322 Quando viene lanciato da \cmd{init} il programma parte con i privilegi di
 323 amministratore e con un ambiente vuoto; \cmd{getty} si cura di chiamare
 324 \func{setsid} per creare una nuova sessione ed un nuovo process group, e di
 325 aprire il terminale (che così diventa il terminale di controllo della
 326 sessione) in lettura sullo standard input ed in scrittura sullo standard
 327 output e sullo standard error; inoltre effettuarà, qualora servano, ulteriori
 328 settaggi.\footnote{ad esempio, come qualcuno si sarà accorto scrivendo un nome
 329   di login in maiuscolo, può effettuare la conversione automatica dell'input
 330   in minuscolo, ponendosi in una modalità speciale che non distingue fra i due
 331   tipi di caratteri (a beneficio di alcuni vecchi terminali che non
 332   supportavano le minuscole).} Alla fine il programma stamperà un messaggio di
 333 benvenuto per poi porsi in attesa dell'immissione del nome di un utente.
 334
 335 Una volta che si sia immesso il nome di login \cmd{getty} esegue direttamente
 336 il programma \cmd{login} con una \func{exevle}, passando come argomento la
 337 stringa con il nome, ed un ambiente opportunamente costruito che contenga
 338 quanto necessario (ad esempio di solito viene opportunamente inizializzata la
 339 variabile di ambiente \texttt{TERM}) ad identificare il terminale su cui si
 340 sta operando, a beneficio dei programmi che verranno lanciati in seguito.
 341
 342 A sua volta \cmd{login}, che mantiene i privilegi di amministratore, usa il
 343 nome dell'utente per effettuare una ricerca nel database degli
 344 utenti,\footnote{in genere viene chiamata \func{getpwnam}, che abbiamo visto
 345   in \secref{sec:sys_user_group}, per leggere la password e gli altri dati dal
 346   database degli utenti.} e richiede una password. Se l'utente non esiste o se
 347 la password non corrisponde\footnote{il confronto non viene effettuato con un
 348   valore in chiaro; quanto immesso da terminale viene invece a sua volta
 349   criptato, ed è il risultato che viene confrontato con il valore che viene
 350   mantenuto nel database degli utenti.} la richiesta viene ripetuta un certo
 351 numero di volte dopo di che \cmd{login} esce ed \cmd{init} provvede a
 352 rilanciare un'altra istanza di \func{getty}.
 353
 354 Se invece la password corrisponde \cmd{login} esegue \func{chdir} per settare
 355 la \textit{home directory} dell'utente, cambia i diritti di accesso al
 356 terminale (con \func{chown} e \func{chmod}) per assegnarne la titolarità
 357 all'utente ed al suo gruppo principale, assegnandogli al contempo i diritti di
 358 lettura e scrittura. Inoltre il programma provvede a costruire gli opportuni
 359 valori per le variabili di ambiente, come \texttt{HOME}, \texttt{SHELL}, ecc.
 360 Infine attraverso l'uso di \func{setuid}, \func{setpid} e \func{initgroups}
 361 verrà cambiata l'identità del proprietario del processo, infatti, come
 362 spiegato in \secref{sec:proc_setuid}, avendo invocato tali funzioni con i
 363 privilegi di amministratore, tutti gli userid ed i groupid (reali, effettivi e
 364 salvati) saranno settati a quelli dell'utente.
 365
 366 A questo punto \cmd{login} provvederà (fatte salve eventuali altre azioni
 367 iniziali, come la stampa di messaggi di benvenuto o il controllo della posta)
 368 ad eseguire con un'altra \func{exec} la shell di login, che si troverà con un
 369 ambiente già pronto e con file standard di \secref{sec:file_std_descr}
 370 impostati sul terminale, pronta ad eseguire i comandi fino all'uscita. Dato
 371 che il processo genitore resta sempre \cmd{init} quest'ultimo provvederà,
 372 ricevendo un \macro{SIGCHLD} all'uscita della shell, a rilanciare \cmd{getty}
 373 per ripetere da capo tutto il procedimento.
 374
 375
 376
 377 \subsection{Prescrizioni per un programma \textit{daemon}}
 378 \label{sec:sess_daemon}
 379
 380 Come sottolineato fin da \secref{sec:intro_base_concept}, in un sistema
 381 unix-like tutte le operazioni sono eseguite tramite processi, comprese quelle
 382 operazioni di sistema (come l'esecuzione di comandi periodici, o la consegna
 383 della posta, ed in generale tutti i programmi di servizio) che non hanno a che
 384 fare con la gestione diretta dei comandi dell'utente.
 385
 386 Questi programmi, che devono essere eseguiti in modalità non interattiva senza
 387 nessun intervento dell'utente, sono normalmente chiamati \textsl{demoni}, (o
 388 \textit{daemons}), nome ispirato dagli omonimi spiritelli che svolgevano vari
 389 compiti, di cui parlava Socrate (che sosteneva di averne uno al suo
 390 servizio).\footnote{NdT. ricontrollare, i miei ricordi di filosofia sono
 391   piuttosto datati.}
 392
 393
 394
 395
 396 \section{L'I/O su terminale}
 397 \label{sec:sess_terminal_io}
 398
 399 Esamineremo in questa sezione le peculiarità dell'I/O su terminale, tenendo
 400 conto delle
 401
 402
 403 %%% Local Variables:
 404 %%% mode: latex
 405 %%% TeX-master: "gapil"
 406 %%% End: