X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=fileunix.tex;h=543c967589716f9707266d8d09c44f6f914d3a09;hp=b4e7b5705a16c2a06b3cfb0001880d285f588150;hb=86e903a44e57cf2d3fe122693fae4319fc8ba89e;hpb=ff2d0141751ed62ef56e5bfd226c589311b8b669

diff --git a/fileunix.tex b/fileunix.tex
index b4e7b57..543c967 100644
--- a/fileunix.tex
+++ b/fileunix.tex
@@ -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,
-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]
@@ -186,7 +186,7 @@ system call del kernel.
 \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}
@@ -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}). \\
-    \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
@@ -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}).}
 
-\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
@@ -387,7 +388,7 @@ estensioni specifiche di Linux, e deve essere definita la macro
 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
@@ -400,7 +401,7 @@ programmi.
 \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}. 
@@ -454,7 +455,7 @@ 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
-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}
@@ -522,7 +523,7 @@ indefinito.
 
 
 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
+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)}
   
@@ -599,7 +600,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
-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)}
 
@@ -628,7 +629,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ò
-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}.
@@ -669,7 +670,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}.
 
-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}
@@ -840,7 +841,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
-  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)}
   
@@ -866,7 +867,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
-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)}
@@ -904,7 +905,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}
-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}.
@@ -951,13 +952,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
-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
-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)}
   
@@ -983,7 +984,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 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
@@ -999,12 +1000,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
-  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
-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}
@@ -1093,9 +1094,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
-  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
-  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}
@@ -1112,7 +1113,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
-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
@@ -1137,7 +1138,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
-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, ...)}