Versione finale del client ECHO su TCP, con esempio di uso della funzione

[gapil.git] / fileunix.tex

diff --git a/fileunix.tex b/fileunix.tex
index b4e7b5705a16c2a06b3cfb0001880d285f588150..6f9334df6dbf7e9fe4610bdb76afa858af1ba646 100644 (file)
--- a/fileunix.tex
+++ b/fileunix.tex
@@ -1,6 +1,6 @@
 %% fileunix.tex
 %%
 %% fileunix.tex
 %%

-%% Copyright (C) 2000-2002 Simone Piccardi.  Permission is granted to
+%% Copyright (C) 2000-2003 Simone Piccardi.  Permission is granted to

 %% copy, distribute and/or modify this document under the terms of the GNU Free
 %% Documentation License, Version 1.1 or any later version published by the
 %% Free Software Foundation; with the Invariant Sections being "Prefazione",
 %% copy, distribute and/or modify this document under the terms of the GNU Free
 %% Documentation License, Version 1.1 or any later version published by the
 %% Free Software Foundation; with the Invariant Sections being "Prefazione",


@@ -50,10 +50,10 @@ Quando un file viene aperto la funzione \func{open} restituisce questo numero,
 tutte le ulteriori operazioni saranno compiute specificando questo stesso
 valore come argomento alle varie funzioni dell'interfaccia.
 
 tutte le ulteriori operazioni saranno compiute specificando questo stesso
 valore come argomento alle varie funzioni dell'interfaccia.
 

-Per capire come funziona il meccanismo occorre spiegare a grandi linee come è
-che il kernel gestisce l'interazione fra processi e file.  Il kernel mantiene
-sempre un elenco dei processi attivi nella cosiddetta \textit{process table}
-ed un elenco dei file aperti nella \textit{file table}.
+Per capire come funziona il meccanismo occorre spiegare a grandi linee come il
+kernel gestisce l'interazione fra processi e file.  Il kernel mantiene sempre
+un elenco dei processi attivi nella cosiddetta \textit{process table} ed un
+elenco dei file aperti nella \textit{file table}.

 
 La \textit{process table} è una tabella che contiene una voce per ciascun
 processo attivo nel sistema. In Linux ciascuna voce è costituita da una
 
 La \textit{process table} è una tabella che contiene una voce per ciascun
 processo attivo nel sistema. In Linux ciascuna voce è costituita da una


@@ -129,7 +129,7 @@ quindi alla lettura della tastiera). Il secondo file 
 inviati i dati in uscita (sempre nel caso della shell, è associato all'uscita
 del terminale, e quindi alla scrittura sullo schermo). Il terzo è lo
 \textit{standard error}, su cui viene inviato l'output relativo agli errori,
 inviati i dati in uscita (sempre nel caso della shell, è associato all'uscita
 del terminale, e quindi alla scrittura sullo schermo). Il terzo è lo
 \textit{standard error}, su cui viene inviato l'output relativo agli errori,

-ed è anch'esso associato all'uscita del termininale.  Lo standard POSIX.1
+ed è anch'esso associato all'uscita del terminale.  Lo standard POSIX.1

 provvede tre costanti simboliche, definite nell'header \file{unistd.h}, al
 posto di questi valori numerici:
 \begin{table}[htb]
 provvede tre costanti simboliche, definite nell'header \file{unistd.h}, al
 posto di questi valori numerici:
 \begin{table}[htb]


@@ -186,7 +186,7 @@ system call del kernel.
 \subsection{La funzione \func{open}}
 \label{sec:file_open}
 
 \subsection{La funzione \func{open}}
 \label{sec:file_open}
 

-La funzione \func{open} è la funzione fondamentale per accedere ai file, ed è
+La funzione \funcd{open} è la funzione fondamentale per accedere ai file, ed è

 quella che crea l'associazione fra un pathname ed un file descriptor, il suo
 prototipo è:
 \begin{functions}
 quella che crea l'associazione fra un pathname ed un file descriptor, il suo
 prototipo è:
 \begin{functions}


@@ -253,7 +253,7 @@ usato sempre il file descriptor con il valore pi
     valore specifica anche una modalità di operazione (vedi sotto), e 
     comporta che \func{open} ritorni immediatamente (l'opzione ha senso 
     solo per le fifo, torneremo questo in \secref{sec:ipc_named_pipe}). \\
     valore specifica anche una modalità di operazione (vedi sotto), e 
     comporta che \func{open} ritorni immediatamente (l'opzione ha senso 
     solo per le fifo, torneremo questo in \secref{sec:ipc_named_pipe}). \\

-    \const{O\_NOCTTY} & se \param{pathname} si riferisce ad un device di
+    \const{O\_NOCTTY} & se \param{pathname} si riferisce ad un dispositivo di

     terminale, questo non diventerà il terminale di controllo, anche se il
     processo non ne ha ancora uno (si veda \secref{sec:sess_ctrl_term}). \\
     \const{O\_SHLOCK} & opzione di BSD, acquisisce uno shared lock (vedi
     terminale, questo non diventerà il terminale di controllo, anche se il
     processo non ne ha ancora uno (si veda \secref{sec:sess_ctrl_term}). \\
     \const{O\_SHLOCK} & opzione di BSD, acquisisce uno shared lock (vedi


@@ -300,7 +300,7 @@ usato sempre il file descriptor con il valore pi
     \func{write} bloccherà fino al completamento della scrittura di tutti dati
     sul sull'hardware sottostante.\\
     \const{O\_FSYNC} & sinonimo di \const{O\_SYNC}. \\
     \func{write} bloccherà fino al completamento della scrittura di tutti dati
     sul sull'hardware sottostante.\\
     \const{O\_FSYNC} & sinonimo di \const{O\_SYNC}. \\

-    \const{O\_NOATIME} & blocca l'aggiornamento dei tempi dei di accesso dei
+    \const{O\_NOATIME} & blocca l'aggiornamento dei tempi di accesso dei

     file (vedi \secref{sec:file_file_times}). In Linux questa opzione non è
     disponibile per il singolo file ma come opzione per il filesystem in fase
     di montaggio.\\
     file (vedi \secref{sec:file_file_times}). In Linux questa opzione non è
     disponibile per il singolo file ma come opzione per il filesystem in fase
     di montaggio.\\


@@ -317,9 +317,10 @@ usato sempre il file descriptor con il valore pi
   file con un nome univoco e la funzione \func{link} per verificarne
   l'esistenza (vedi \secref{sec:ipc_file_lock}).}
 
   file con un nome univoco e la funzione \func{link} per verificarne
   l'esistenza (vedi \secref{sec:ipc_file_lock}).}
 

-\footnotetext[3]{\textit{Denial of Service}, si chiamano così attacchi miranti
-  ad impedire un servizio causando una qualche forma di carico eccessivo per
-  il sistema, che resta bloccato nelle risposte all'attacco.}
+\footnotetext[3]{\textit{Denial of Service}\index{DoS}, si chiamano così
+  attacchi miranti ad impedire un servizio causando una qualche forma di
+  carico eccessivo per il sistema, che resta bloccato nelle risposte
+  all'attacco.}

 
 \footnotetext[4]{il problema è che NFS non supporta la scrittura in append, ed
   il kernel deve simularla, ma questo comporta la possibilità di una race
 
 \footnotetext[4]{il problema è che NFS non supporta la scrittura in append, ed
   il kernel deve simularla, ma questo comporta la possibilità di una race


@@ -335,20 +336,17 @@ descriptor che si otterr
 alcune applicazioni per sostituire i file corrispondenti ai file standard
 visti in \secref{sec:file_std_descr}: se ad esempio si chiude lo standard
 input e si apre subito dopo un nuovo file questo diventerà il nuovo standard
 alcune applicazioni per sostituire i file corrispondenti ai file standard
 visti in \secref{sec:file_std_descr}: se ad esempio si chiude lo standard
 input e si apre subito dopo un nuovo file questo diventerà il nuovo standard

-input (avrà cioè il file descriptor 0).
-
-Il nuovo file descriptor non è condiviso con nessun altro processo (torneremo
-sulla condivisione dei file, in genere accessibile dopo una \func{fork}, in
-\secref{sec:file_sharing}). Il nuovo file descriptor è impostato per restare
-aperto attraverso una \func{exec} (come accennato in \secref{sec:proc_exec}) e
-l'offset è impostato all'inizio del file.
-
-L'argomento \param{mode} specifica i permessi con cui il file viene
-eventualmente creato; i valori possibili sono gli stessi già visti in
-\secref{sec:file_perm_overview} e possono essere specificati come OR binario
-delle costanti descritte in \tabref{tab:file_bit_perm}. Questi permessi sono
-filtrati dal valore di \var{umask} (vedi \secref{sec:file_umask}) per il
-processo.
+input (avrà cioè il file descriptor 0).  Il nuovo file descriptor non è
+condiviso con nessun altro processo (torneremo sulla condivisione dei file, in
+genere accessibile dopo una \func{fork}, in \secref{sec:file_sharing}) ed è
+impostato per restare aperto attraverso una \func{exec} (come accennato in
+\secref{sec:proc_exec}); l'offset è impostato all'inizio del file.
+
+L'argomento \param{mode} indica i permessi con cui il file viene creato; i
+valori possibili sono gli stessi già visti in \secref{sec:file_perm_overview}
+e possono essere specificati come OR binario delle costanti descritte in
+\tabref{tab:file_bit_perm}. Questi permessi sono filtrati dal valore di
+\var{umask} (vedi \secref{sec:file_umask}) per il processo.

 
 La funzione prevede diverse opzioni, che vengono specificate usando vari bit
 dell'argomento \param{flags}.  Alcuni di questi bit vanno anche a costituire
 
 La funzione prevede diverse opzioni, che vengono specificate usando vari bit
 dell'argomento \param{flags}.  Alcuni di questi bit vanno anche a costituire


@@ -356,38 +354,38 @@ il flag di stato del file (o \textit{file status flag}), che 
 campo \var{f\_flags} della struttura \struct{file} (al solito si veda lo schema
 di \figref{fig:file_proc_file}).  Essi sono divisi in tre categorie
 principali:
 campo \var{f\_flags} della struttura \struct{file} (al solito si veda lo schema
 di \figref{fig:file_proc_file}).  Essi sono divisi in tre categorie
 principali:

-\begin{itemize}
+\begin{itemize*}

 \item \textsl{i bit delle modalità di accesso}: specificano con quale modalità
   si accederà al file: i valori possibili sono lettura, scrittura o
   lettura/scrittura.  Uno di questi bit deve essere sempre specificato quando
   si apre un file.  Vengono impostati alla chiamata da \func{open}, e possono
 \item \textsl{i bit delle modalità di accesso}: specificano con quale modalità
   si accederà al file: i valori possibili sono lettura, scrittura o
   lettura/scrittura.  Uno di questi bit deve essere sempre specificato quando
   si apre un file.  Vengono impostati alla chiamata da \func{open}, e possono

-  essere riletti con una \func{fcntl} (fanno parte del \textit{file status
-    flag}), ma non possono essere modificati.
+  essere riletti con \func{fcntl} (fanno parte del \textit{file status flag}),
+  ma non possono essere modificati.

 \item \textsl{i bit delle modalità di apertura}: permettono di specificare
   alcune delle caratteristiche del comportamento di \func{open} quando viene
   eseguita. Hanno effetto solo al momento della chiamata della funzione e non
   sono memorizzati né possono essere riletti.
 \item \textsl{i bit delle modalità di operazione}: permettono di specificare
   alcune caratteristiche del comportamento delle future operazioni sul file
 \item \textsl{i bit delle modalità di apertura}: permettono di specificare
   alcune delle caratteristiche del comportamento di \func{open} quando viene
   eseguita. Hanno effetto solo al momento della chiamata della funzione e non
   sono memorizzati né possono essere riletti.
 \item \textsl{i bit delle modalità di operazione}: permettono di specificare
   alcune caratteristiche del comportamento delle future operazioni sul file

-  (come la \func{read} o la \func{write}). Anch'essi fanno parte del
-  \textit{file status flag}. Il loro valore è impostato alla chiamata di
-  \func{open}, ma possono essere riletti e modificati (insieme alle
-  caratteristiche operative che controllano) con una \func{fcntl}.
-\end{itemize}
+  (come \func{read} o \func{write}). Anch'essi fan parte del \textit{file
+    status flag}. Il loro valore è impostato alla chiamata di \func{open}, ma
+  possono essere riletti e modificati (insieme alle caratteristiche operative
+  che controllano) con una \func{fcntl}.
+\end{itemize*}

 
 

-In \tabref{tab:file_open_flags} si sono riportate, ordinate e divise fra loro
+In \tabref{tab:file_open_flags} sono riportate, ordinate e divise fra loro

 secondo le tre modalità appena elencate, le costanti mnemoniche associate a
 secondo le tre modalità appena elencate, le costanti mnemoniche associate a

-ciascuno di questi bit. Dette costanti possono essere combinate fra di loro
-con un OR aritmetico per costruire il valore (in forma di maschera binaria)
-dell'argomento \param{flags} da passare alla \func{open} per specificarne il
-comportamento. I due flag \const{O\_NOFOLLOW} e \const{O\_DIRECTORY} sono
-estensioni specifiche di Linux, e deve essere definita la macro
-\macro{\_GNU\_SOURCE} per poterli usare.
+ciascuno di questi bit. Dette costanti possono essere combinate fra loro con
+un OR aritmetico per costruire il valore (in forma di maschera binaria)
+dell'argomento \param{flags} da passare alla \func{open}. I due flag
+\const{O\_NOFOLLOW} e \const{O\_DIRECTORY} sono estensioni specifiche di
+Linux, e deve essere definita la macro \macro{\_GNU\_SOURCE} per poterli
+usare.

 
 Nelle prime versioni di Unix i valori di \param{flag} specificabili per
 \func{open} erano solo quelli relativi alle modalità di accesso del file.  Per
 questo motivo per creare un nuovo file c'era una system call apposita,
 
 Nelle prime versioni di Unix i valori di \param{flag} specificabili per
 \func{open} erano solo quelli relativi alle modalità di accesso del file.  Per
 questo motivo per creare un nuovo file c'era una system call apposita,

-\func{creat}, il cui prototipo è:
+\funcd{creat}, il cui prototipo è:

 \begin{prototype}{fcntl.h}
   {int creat(const char *pathname, mode\_t mode)}
   Crea un nuovo file vuoto, con i permessi specificati da \param{mode}. È del
 \begin{prototype}{fcntl.h}
   {int creat(const char *pathname, mode\_t mode)}
   Crea un nuovo file vuoto, con i permessi specificati da \param{mode}. È del


@@ -400,13 +398,13 @@ programmi.
 \subsection{La funzione \func{close}}
 \label{sec:file_close}
 
 \subsection{La funzione \func{close}}
 \label{sec:file_close}
 

-La funzione \func{close} permette di chiudere un file, in questo modo il file
+La funzione \funcd{close} permette di chiudere un file, in questo modo il file

 descriptor ritorna disponibile; il suo prototipo è:
 \begin{prototype}{unistd.h}{int close(int fd)}
   Chiude il descrittore \param{fd}. 
   
   \bodydesc{La funzione ritorna 0 in caso di successo e -1 in caso di errore,
 descriptor ritorna disponibile; il suo prototipo è:
 \begin{prototype}{unistd.h}{int close(int fd)}
   Chiude il descrittore \param{fd}. 
   
   \bodydesc{La funzione ritorna 0 in caso di successo e -1 in caso di errore,

-    ed in questo caso \var{errno} assumerà uno dei valori:
+    con \var{errno} che assume i valori:

   \begin{errlist}
     \item[\errcode{EBADF}]  \param{fd} non è un descrittore valido.
     \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
   \begin{errlist}
     \item[\errcode{EBADF}]  \param{fd} non è un descrittore valido.
     \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.


@@ -454,14 +452,14 @@ automaticamente spostata in avanti del numero di byte letti o scritti.
 
 In genere (a meno di non avere richiesto la modalità \const{O\_APPEND}) questa
 posizione viene impostata a zero all'apertura del file. È possibile impostarla
 
 In genere (a meno di non avere richiesto la modalità \const{O\_APPEND}) questa
 posizione viene impostata a zero all'apertura del file. È possibile impostarla

-ad un valore qualsiasi con la funzione \func{lseek}, il cui prototipo è:
+ad un valore qualsiasi con la funzione \funcd{lseek}, il cui prototipo è:

 \begin{functions}
   \headdecl{sys/types.h}
   \headdecl{unistd.h}
   \funcdecl{off\_t lseek(int fd, off\_t offset, int whence)}
   Imposta la posizione attuale nel file. 
   
 \begin{functions}
   \headdecl{sys/types.h}
   \headdecl{unistd.h}
   \funcdecl{off\_t lseek(int fd, off\_t offset, int whence)}
   Imposta la posizione attuale nel file. 
   

-  \bodydesc{La funzione ritorna valore della posizione corrente in caso di
+  \bodydesc{La funzione ritorna il valore della posizione corrente in caso di

     successo e -1 in caso di errore nel qual caso \var{errno} assumerà uno dei
     valori:
   \begin{errlist}
     successo e -1 in caso di errore nel qual caso \var{errno} assumerà uno dei
     valori:
   \begin{errlist}


@@ -491,20 +489,19 @@ seguenti valori\footnote{per compatibilit
 
 Come accennato in \secref{sec:file_file_size} con \func{lseek} è possibile
 impostare la posizione corrente anche oltre la fine del file, e alla
 
 Come accennato in \secref{sec:file_file_size} con \func{lseek} è possibile
 impostare la posizione corrente anche oltre la fine del file, e alla

-successiva scrittura il file sarà esteso. La chiamata non causa nessuna
-attività di input/output, si limita a modificare la posizione corrente nel
-kernel (cioè \var{f\_pos} in \param{file}, vedi \figref{fig:file_proc_file}).
-
-Dato che la funzione ritorna la nuova posizione, usando il valore zero per
-\param{offset} si può riottenere la posizione corrente nel file chiamando la
-funzione con \code{lseek(fd, 0, SEEK\_CUR)}. 
+successiva scrittura il file sarà esteso. La chiamata non causa nessun accesso
+al file, si limita a modificare la posizione corrente (cioè il valore
+\var{f\_pos} in \param{file}, vedi \figref{fig:file_proc_file}).  Dato che la
+funzione ritorna la nuova posizione, usando il valore zero per \param{offset}
+si può riottenere la posizione corrente nel file chiamando la funzione con
+\code{lseek(fd, 0, SEEK\_CUR)}.

 
 Si tenga presente inoltre che usare \const{SEEK\_END} non assicura affatto che
 la successiva scrittura avvenga alla fine del file, infatti se questo è stato
 aperto anche da un altro processo che vi ha scritto, la fine del file può
 essersi spostata, ma noi scriveremo alla posizione impostata in precedenza
 
 Si tenga presente inoltre che usare \const{SEEK\_END} non assicura affatto che
 la successiva scrittura avvenga alla fine del file, infatti se questo è stato
 aperto anche da un altro processo che vi ha scritto, la fine del file può
 essersi spostata, ma noi scriveremo alla posizione impostata in precedenza

-(questa è una potenziale sorgente di \textit{race condition}
-\index{race condition}, vedi \secref{sec:file_atomic}).
+(questa è una potenziale sorgente di 
+\textit{race condition}\index{race condition}, vedi \secref{sec:file_atomic}).

 
 Non tutti i file supportano la capacità di eseguire una \func{lseek}, in
 questo caso la funzione ritorna l'errore \errcode{EPIPE}. Questo, oltre che per
 
 Non tutti i file supportano la capacità di eseguire una \func{lseek}, in
 questo caso la funzione ritorna l'errore \errcode{EPIPE}. Questo, oltre che per


@@ -521,8 +518,8 @@ indefinito.
 \label{sec:file_read}
 
 
 \label{sec:file_read}
 
 

-Una volta che un file è stato aperto (con il permesso in lettura) su possono
-leggere i dati che contiene utilizzando la funzione \func{read}, il cui
+Una volta che un file è stato aperto (con il permesso in lettura) si possono
+leggere i dati che contiene utilizzando la funzione \funcd{read}, il cui

 prototipo è:
 \begin{prototype}{unistd.h}{ssize\_t read(int fd, void * buf, size\_t count)}
   
 prototipo è:
 \begin{prototype}{unistd.h}{ssize\_t read(int fd, void * buf, size\_t count)}
   


@@ -545,24 +542,21 @@ prototipo 
 La funzione tenta di leggere \param{count} byte a partire dalla posizione
 corrente nel file. Dopo la lettura la posizione sul file è spostata
 automaticamente in avanti del numero di byte letti. Se \param{count} è zero la
 La funzione tenta di leggere \param{count} byte a partire dalla posizione
 corrente nel file. Dopo la lettura la posizione sul file è spostata
 automaticamente in avanti del numero di byte letti. Se \param{count} è zero la

-funzione restituisce zero senza nessun altro risultato.
-
-Si deve sempre tener presente che non è detto che la funzione \func{read}
-restituisca sempre il numero di byte richiesto, ci sono infatti varie ragioni
-per cui la funzione può restituire un numero di byte inferiore; questo è un
-comportamento normale, e non un errore, che bisogna sempre tenere presente.
+funzione restituisce zero senza nessun altro risultato.  Si deve sempre tener
+presente che non è detto che la funzione \func{read} restituisca sempre il
+numero di byte richiesto, ci sono infatti varie ragioni per cui la funzione
+può restituire un numero di byte inferiore; questo è un comportamento normale,
+e non un errore, che bisogna sempre tenere presente.  

 
 La prima e più ovvia di queste ragioni è che si è chiesto di leggere più byte
 di quanto il file ne contenga. In questo caso il file viene letto fino alla
 sua fine, e la funzione ritorna regolarmente il numero di byte letti
 
 La prima e più ovvia di queste ragioni è che si è chiesto di leggere più byte
 di quanto il file ne contenga. In questo caso il file viene letto fino alla
 sua fine, e la funzione ritorna regolarmente il numero di byte letti

-effettivamente. 
-
-Raggiunta la fine del file, alla ripetizione di un'operazione di lettura,
-otterremmo il ritorno immediato di \func{read} con uno zero.  La condizione di
-raggiungimento della fine del file non è un errore, e viene segnalata appunto
-da un valore di ritorno di \func{read} nullo. Ripetere ulteriormente la
-lettura non avrebbe nessun effetto se non quello di continuare a ricevere zero
-come valore di ritorno.
+effettivamente. Raggiunta la fine del file, alla ripetizione di un'operazione
+di lettura, otterremmo il ritorno immediato di \func{read} con uno zero.  La
+condizione di raggiungimento della fine del file non è un errore, e viene
+segnalata appunto da un valore di ritorno di \func{read} nullo. Ripetere
+ulteriormente la lettura non avrebbe nessun effetto se non quello di
+continuare a ricevere zero come valore di ritorno.

 
 Con i \textsl{file regolari} questa è l'unica situazione in cui si può avere
 un numero di byte letti inferiore a quello richiesto, ma questo non è vero
 
 Con i \textsl{file regolari} questa è l'unica situazione in cui si può avere
 un numero di byte letti inferiore a quello richiesto, ma questo non è vero


@@ -576,20 +570,19 @@ con un numero di byte inferiore a quelli richiesti.
 Lo stesso comportamento avviene caso di lettura dalla rete (cioè su un
 socket\index{socket}, come vedremo in \secref{sec:sock_io_behav}), o per la
 lettura da certi file di dispositivo, come le unità a nastro, che
 Lo stesso comportamento avviene caso di lettura dalla rete (cioè su un
 socket\index{socket}, come vedremo in \secref{sec:sock_io_behav}), o per la
 lettura da certi file di dispositivo, come le unità a nastro, che

-restituiscono sempre i dati ad un singolo blocco alla volta.
+restituiscono sempre i dati ad un singolo blocco alla volta.  

 
 In realtà anche le due condizioni segnalate dagli errori \errcode{EINTR} e
 \errcode{EAGAIN} non sono errori. La prima si verifica quando la \func{read} è
 bloccata in attesa di dati in ingresso e viene interrotta da un segnale; in
 tal caso l'azione da intraprendere è quella di rieseguire la funzione.
 
 In realtà anche le due condizioni segnalate dagli errori \errcode{EINTR} e
 \errcode{EAGAIN} non sono errori. La prima si verifica quando la \func{read} è
 bloccata in attesa di dati in ingresso e viene interrotta da un segnale; in
 tal caso l'azione da intraprendere è quella di rieseguire la funzione.

-Torneremo in dettaglio sull'argomento in \secref{sec:sig_gen_beha}.
-
-La seconda si verifica quando il file è in modalità non bloccante (vedi
+Torneremo in dettaglio sull'argomento in \secref{sec:sig_gen_beha}.  La
+seconda si verifica quando il file è in modalità non bloccante (vedi

 \secref{sec:file_noblocking}) e non ci sono dati in ingresso: la funzione
 \secref{sec:file_noblocking}) e non ci sono dati in ingresso: la funzione

-allora ritorna immediatamente con un errore \errcode{EAGAIN}\footnote{sotto
-  BSD per questo errore viene usata la costante \errcode{EWOULDBLOCK}, in
-  Linux, con le glibc, questa è sinonima di \errcode{EAGAIN}.} che indica
-soltanto che occorrerà provare a ripetere la lettura.
+allora ritorna immediatamente con un errore \errcode{EAGAIN}\footnote{BSD usa
+  per questo errore la costante \errcode{EWOULDBLOCK}, in Linux, con le
+  \acr{glibc}, questa è sinonima di \errcode{EAGAIN}.} che indica soltanto che
+occorrerà provare a ripetere la lettura.

 
 La funzione \func{read} è una delle system call fondamentali, esistenti fin
 dagli albori di Unix, ma nella seconda versione delle \textit{Single Unix
 
 La funzione \func{read} è una delle system call fondamentali, esistenti fin
 dagli albori di Unix, ma nella seconda versione delle \textit{Single Unix


@@ -599,7 +592,7 @@ dagli albori di Unix, ma nella seconda versione delle \textit{Single Unix
   aggiunto con la versione 2.1, in versioni precedenti sia del kernel che
   delle librerie la funzione non è disponibile.} (quello che viene chiamato
 normalmente Unix98, vedi \secref{sec:intro_opengroup}) è stata introdotta la
   aggiunto con la versione 2.1, in versioni precedenti sia del kernel che
   delle librerie la funzione non è disponibile.} (quello che viene chiamato
 normalmente Unix98, vedi \secref{sec:intro_opengroup}) è stata introdotta la

-definizione di un'altra funzione di lettura, \func{pread}, il cui prototipo è:
+definizione di un'altra funzione di lettura, \funcd{pread}, il cui prototipo è:

 \begin{prototype}{unistd.h}
 {ssize\_t pread(int fd, void * buf, size\_t count, off\_t offset)}
 
 \begin{prototype}{unistd.h}
 {ssize\_t pread(int fd, void * buf, size\_t count, off\_t offset)}
 


@@ -612,7 +605,7 @@ posizione \param{offset}, nel buffer \param{buf}.
 \end{prototype}
 \noindent che però diventa accessibile solo con la definizione della macro:
 \begin{verbatim}
 \end{prototype}
 \noindent che però diventa accessibile solo con la definizione della macro:
 \begin{verbatim}

-       #define _XOPEN_SOURCE 500
+#define _XOPEN_SOURCE 500

 \end{verbatim}
 
 Questa funzione serve quando si vogliono leggere dati dal file senza
 \end{verbatim}
 
 Questa funzione serve quando si vogliono leggere dati dal file senza


@@ -628,7 +621,7 @@ condivisa da processi diversi (vedi \secref{sec:file_sharing}).  Il valore di
 \label{sec:file_write}
 
 Una volta che un file è stato aperto (con il permesso in scrittura) su può
 \label{sec:file_write}
 
 Una volta che un file è stato aperto (con il permesso in scrittura) su può

-scrivere su di esso utilizzando la funzione \func{write}, il cui prototipo è:
+scrivere su di esso utilizzando la funzione \funcd{write}, il cui prototipo è:

 \begin{prototype}{unistd.h}{ssize\_t write(int fd, void * buf, size\_t count)}
   
   Scrive \param{count} byte dal buffer \param{buf} sul file \param{fd}.
 \begin{prototype}{unistd.h}{ssize\_t write(int fd, void * buf, size\_t count)}
   
   Scrive \param{count} byte dal buffer \param{buf} sul file \param{fd}.


@@ -645,10 +638,10 @@ scrivere su di esso utilizzando la funzione \func{write}, il cui prototipo 
     chiuso in lettura; in questo caso viene anche generato il segnale
     \const{SIGPIPE}, se questo viene gestito (o bloccato o ignorato) la
     funzione ritorna questo errore.
     chiuso in lettura; in questo caso viene anche generato il segnale
     \const{SIGPIPE}, se questo viene gestito (o bloccato o ignorato) la
     funzione ritorna questo errore.

-  \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale prima di
-    aver potuto scrivere qualsiasi dato.
-  \item[\errcode{EAGAIN}] la funzione non aveva nessun dato da restituire e si
-    era aperto il file in modalità \const{O\_NONBLOCK}.
+  \item[\errcode{EINTR}] si è stati interrotti da un segnale prima di aver
+    potuto scrivere qualsiasi dato.
+  \item[\errcode{EAGAIN}] ci si sarebbe bloccati, ma il file era aperto in
+    modalità \const{O\_NONBLOCK}.

   \end{errlist}
   ed inoltre \errval{EBADF}, \errval{EIO}, \errval{EISDIR}, \errval{EBADF},
   \errval{ENOSPC}, \errval{EINVAL} e \errval{EFAULT} ed eventuali altri errori
   \end{errlist}
   ed inoltre \errval{EBADF}, \errval{EIO}, \errval{EISDIR}, \errval{EBADF},
   \errval{ENOSPC}, \errval{EINVAL} e \errval{EFAULT} ed eventuali altri errori


@@ -669,7 +662,7 @@ Per i file ordinari il numero di byte scritti 
 indicato da \param{count}, a meno di un errore. Negli altri casi si ha lo
 stesso comportamento di \func{read}.
 
 indicato da \param{count}, a meno di un errore. Negli altri casi si ha lo
 stesso comportamento di \func{read}.
 

-Anche per \func{write} lo standard Unix98 definisce un'analoga \func{pwrite}
+Anche per \func{write} lo standard Unix98 definisce un'analoga \funcd{pwrite}

 per scrivere alla posizione indicata senza modificare la posizione corrente
 nel file, il suo prototipo è:
 \begin{prototype}{unistd.h}
 per scrivere alla posizione indicata senza modificare la posizione corrente
 nel file, il suo prototipo è:
 \begin{prototype}{unistd.h}


@@ -712,7 +705,7 @@ confronti dell'accesso allo stesso file da parte di processi diversi.
   \label{fig:file_mult_acc}
 \end{figure}
 
   \label{fig:file_mult_acc}
 \end{figure}
 

-Il primo caso è quello in cui due processi diversi che aprono lo stesso file
+Il primo caso è quello in cui due processi diversi aprono lo stesso file

 su disco; sulla base di quanto visto in \secref{sec:file_fd} avremo una
 situazione come quella illustrata in \figref{fig:file_mult_acc}: ciascun
 processo avrà una sua voce nella \textit{file table} referenziata da un
 su disco; sulla base di quanto visto in \secref{sec:file_fd} avremo una
 situazione come quella illustrata in \figref{fig:file_mult_acc}: ciascun
 processo avrà una sua voce nella \textit{file table} referenziata da un


@@ -840,7 +833,7 @@ scarico dei dati dai buffer del kernel.\footnote{come gi
   questo dà la garanzia assoluta che i dati siano integri dopo la chiamata,
   l'hardware dei dischi è in genere dotato di un suo meccanismo interno di
   ottimizzazione per l'accesso al disco che può ritardare ulteriormente la
   questo dà la garanzia assoluta che i dati siano integri dopo la chiamata,
   l'hardware dei dischi è in genere dotato di un suo meccanismo interno di
   ottimizzazione per l'accesso al disco che può ritardare ulteriormente la

-  scrittura effettiva.} La prima di queste funzioni è \func{sync} il cui
+  scrittura effettiva.} La prima di queste funzioni è \funcd{sync} il cui

 prototipo è:
 \begin{prototype}{unistd.h}{int sync(void)}
   
 prototipo è:
 \begin{prototype}{unistd.h}{int sync(void)}
   


@@ -866,7 +859,7 @@ significato dei valori si pu
 
 Quando si vogliono scaricare soltanto i dati di un file (ad esempio essere
 sicuri che i dati di un database sono stati registrati su disco) si possono
 
 Quando si vogliono scaricare soltanto i dati di un file (ad esempio essere
 sicuri che i dati di un database sono stati registrati su disco) si possono

-usare le due funzioni \func{fsync} e \func{fdatasync}, i cui prototipi sono:
+usare le due funzioni \funcd{fsync} e \funcd{fdatasync}, i cui prototipi sono:

 \begin{functions}
   \headdecl{unistd.h}
   \funcdecl{int fsync(int fd)}
 \begin{functions}
   \headdecl{unistd.h}
   \funcdecl{int fsync(int fd)}


@@ -904,7 +897,7 @@ disco) che deve essere effettuata esplicitamente.\footnote{in realt
 Abbiamo già visto in \secref{sec:file_sharing} come un processo figlio
 condivida gli stessi file descriptor del padre; è possibile però ottenere un
 comportamento analogo all'interno di uno stesso processo \textit{duplicando}
 Abbiamo già visto in \secref{sec:file_sharing} come un processo figlio
 condivida gli stessi file descriptor del padre; è possibile però ottenere un
 comportamento analogo all'interno di uno stesso processo \textit{duplicando}

-un file descriptor. Per far questo si usa la funzione \func{dup} il cui
+un file descriptor. Per far questo si usa la funzione \funcd{dup} il cui

 prototipo è:
 \begin{prototype}{unistd.h}{int dup(int oldfd)}
   Crea una copia del file descriptor \param{oldfd}.
 prototipo è:
 \begin{prototype}{unistd.h}{int dup(int oldfd)}
   Crea una copia del file descriptor \param{oldfd}.


@@ -951,13 +944,13 @@ dell'output fra l'esecuzione di una \func{fork} e la successiva \func{exec};
 diventa così possibile associare un file (o una pipe) allo standard input o
 allo standard output (torneremo sull'argomento in \secref{sec:ipc_pipe_use},
 quando tratteremo le pipe). Per fare questo in genere occorre prima chiudere
 diventa così possibile associare un file (o una pipe) allo standard input o
 allo standard output (torneremo sull'argomento in \secref{sec:ipc_pipe_use},
 quando tratteremo le pipe). Per fare questo in genere occorre prima chiudere

-il file che si vuole sostituire, cossicché il suo file descriptor possa esser
+il file che si vuole sostituire, cosicché il suo file descriptor possa esser

 restituito alla chiamata di \func{dup}, come primo file descriptor
 disponibile.
 
 Dato che questa è l'operazione più comune, è prevista una diversa versione
 restituito alla chiamata di \func{dup}, come primo file descriptor
 disponibile.
 
 Dato che questa è l'operazione più comune, è prevista una diversa versione

-della funzione, \func{dup2}, che permette di specificare esplicitamente qual'è
-il valore di file descriptor che si vuole avere come duplicato; il suo
+della funzione, \funcd{dup2}, che permette di specificare esplicitamente
+qual'è il valore di file descriptor che si vuole avere come duplicato; il suo

 prototipo è:
 \begin{prototype}{unistd.h}{int dup2(int oldfd, int newfd)}
   
 prototipo è:
 \begin{prototype}{unistd.h}{int dup2(int oldfd, int newfd)}
   


@@ -983,7 +976,7 @@ funzione di controllo dei file \func{fnctl} (che esamineremo in
 la sintassi \code{fnctl(oldfd, F\_DUPFD, newfd)} e se si usa 0 come valore per
 \param{newfd} diventa equivalente a \func{dup}. 
 
 la sintassi \code{fnctl(oldfd, F\_DUPFD, newfd)} e se si usa 0 come valore per
 \param{newfd} diventa equivalente a \func{dup}. 
 

-La sola differenza fra le due funzioni\footnote{a parte la sistassi ed i
+La sola differenza fra le due funzioni\footnote{a parte la sintassi ed i

   diversi codici di errore.} è che \func{dup2} chiude il file descriptor
 \param{newfd} se questo è già aperto, garantendo che la duplicazione sia
 effettuata esattamente su di esso, invece \func{fcntl} restituisce il primo
   diversi codici di errore.} è che \func{dup2} chiude il file descriptor
 \param{newfd} se questo è già aperto, garantendo che la duplicazione sia
 effettuata esattamente su di esso, invece \func{fcntl} restituisce il primo


@@ -999,12 +992,12 @@ tutta una serie di operazioni ausiliarie che 
 descriptor, che non riguardano la normale lettura e scrittura di dati, ma la
 gestione sia delle loro proprietà, che di tutta una serie di ulteriori
 funzionalità che il kernel può mettere a disposizione.\footnote{ad esempio si
 descriptor, che non riguardano la normale lettura e scrittura di dati, ma la
 gestione sia delle loro proprietà, che di tutta una serie di ulteriori
 funzionalità che il kernel può mettere a disposizione.\footnote{ad esempio si

-  gesticono con questa funzione l'I/O asincrono (vedi
+  gestiscono con questa funzione l'I/O asincrono (vedi

   \secref{sec:file_asyncronous_io}) e il file locking\index{file!locking}
   (vedi \secref{sec:file_locking}).}
 
 Per queste operazioni di manipolazione e di controllo su proprietà e
   \secref{sec:file_asyncronous_io}) e il file locking\index{file!locking}
   (vedi \secref{sec:file_locking}).}
 
 Per queste operazioni di manipolazione e di controllo su proprietà e

-caratteristiche un file descriptor, viene usata la funzione \func{fcntl}, il
+caratteristiche un file descriptor, viene usata la funzione \funcd{fcntl}, il

 cui prototipo è:
 \begin{functions}
   \headdecl{unistd.h}
 cui prototipo è:
 \begin{functions}
   \headdecl{unistd.h}


@@ -1093,9 +1086,9 @@ valori 
   valore zero indica di usare il segnale predefinito, \const{SIGIO}. Un altro
   valore (compreso lo stesso \const{SIGIO}) specifica il segnale voluto; l'uso
   di un valore diverso da zero permette inoltre, se si è installato il
   valore zero indica di usare il segnale predefinito, \const{SIGIO}. Un altro
   valore (compreso lo stesso \const{SIGIO}) specifica il segnale voluto; l'uso
   di un valore diverso da zero permette inoltre, se si è installato il

-  manipolatore del segnale come \var{sa\_sigaction} usando
+  gestore del segnale come \var{sa\_sigaction} usando

   \const{SA\_SIGINFO}, (vedi \secref{sec:sig_sigaction}), di rendere
   \const{SA\_SIGINFO}, (vedi \secref{sec:sig_sigaction}), di rendere

-  disponibili al manipolatore informazioni ulteriori informazioni riguardo il
+  disponibili al gestore informazioni ulteriori informazioni riguardo il

   file che ha generato il segnale attraverso i valori restituiti in
   \struct{siginfo\_t} (come vedremo in
   \secref{sec:file_asyncronous_io}).\footnote{i due comandi \const{F\_SETSIG}
   file che ha generato il segnale attraverso i valori restituiti in
   \struct{siginfo\_t} (come vedremo in
   \secref{sec:file_asyncronous_io}).\footnote{i due comandi \const{F\_SETSIG}


@@ -1112,7 +1105,7 @@ le tematiche relative all'I/O asincrono sono trattate in maniera esaustiva in
 
 Si tenga presente infine che quando si usa la funzione per determinare le
 modalità di accesso con cui è stato aperto il file (attraverso l'uso del
 
 Si tenga presente infine che quando si usa la funzione per determinare le
 modalità di accesso con cui è stato aperto il file (attraverso l'uso del

-comando \const{F\_GETFL}) è necessario estrarre i bit corripondenti nel
+comando \const{F\_GETFL}) è necessario estrarre i bit corrispondenti nel

 \textit{file status flag} che si è ottenuto.  Infatti la definizione corrente
 di quest'ultimo non assegna bit separati alle tre diverse modalità
 \const{O\_RDONLY}, \const{O\_WRONLY} e \const{O\_RDWR}.\footnote{in Linux
 \textit{file status flag} che si è ottenuto.  Infatti la definizione corrente
 di quest'ultimo non assegna bit separati alle tre diverse modalità
 \const{O\_RDONLY}, \const{O\_WRONLY} e \const{O\_RDWR}.\footnote{in Linux


@@ -1137,7 +1130,7 @@ interfaccia astratta (un caso tipico 
 porta seriale, o le dimensioni di un framebuffer).
 
 Per questo motivo nell'architettura del sistema è stata prevista l'esistenza
 porta seriale, o le dimensioni di un framebuffer).
 
 Per questo motivo nell'architettura del sistema è stata prevista l'esistenza

-di una funzione apposita, \func{ioctl}, con cui poter compiere le operazioni
+di una funzione apposita, \funcd{ioctl}, con cui poter compiere le operazioni

 specifiche di ogni dispositivo particolare, usando come riferimento il solito
 file descriptor.  Il prototipo di questa funzione è:
 \begin{prototype}{sys/ioctl.h}{int ioctl(int fd, int request, ...)}  
 specifiche di ogni dispositivo particolare, usando come riferimento il solito
 file descriptor.  Il prototipo di questa funzione è:
 \begin{prototype}{sys/ioctl.h}{int ioctl(int fd, int request, ...)}