Integrate una altra serie di correzioni e riscritte parti coi suggerimenti

[gapil.git] / fileintro.tex

diff --git a/fileintro.tex b/fileintro.tex
index 40d8e2575d262890ff440b6f165c95eb1f563537..15e2fd82fbd77d9004b4fccd7973c75d691d57c7 100644 (file)
--- a/fileintro.tex
+++ b/fileintro.tex
@@ -90,10 +90,11 @@ risoluzione del nome (\textit{file name resolution} o \textit{pathname
   resolution}).  La risoluzione viene fatta esaminando il \textit{pathname} da
 sinistra a destra e localizzando ogni nome nella directory indicata dal nome
 precedente usando \file{/} come separatore\footnote{nel caso di nome vuoto, il
   resolution}).  La risoluzione viene fatta esaminando il \textit{pathname} da
 sinistra a destra e localizzando ogni nome nella directory indicata dal nome
 precedente usando \file{/} come separatore\footnote{nel caso di nome vuoto, il

-  costrutto \file{//} viene considerato equivalente a \file{/}.}: ovviamente
-perché il procedimento funzioni occorre che i nomi indicati come directory
+  costrutto \file{//} viene considerato equivalente a \file{/}.}: ovviamente,
+perché il procedimento funzioni, occorre che i nomi indicati come directory

 esistano e siano effettivamente directory, inoltre i permessi (si veda
 esistano e siano effettivamente directory, inoltre i permessi (si veda

-\secref{sec:file_access_control}) devono consentire l'accesso.
+\secref{sec:file_access_control}) devono consentire l'accesso all'intero
+\textit{pathname}.

 
 Se il \textit{pathname} comincia per \file{/} la ricerca parte dalla directory
 radice del processo; questa, a meno di un \func{chroot} (su cui torneremo in
 
 Se il \textit{pathname} comincia per \file{/} la ricerca parte dalla directory
 radice del processo; questa, a meno di un \func{chroot} (su cui torneremo in


@@ -105,16 +106,16 @@ parte dalla directory corrente (su cui torneremo in
   relativo}\index{pathname relativo}.
 
 I nomi \file{.} e \file{..} hanno un significato speciale e vengono inseriti
   relativo}\index{pathname relativo}.
 
 I nomi \file{.} e \file{..} hanno un significato speciale e vengono inseriti

-in ogni directory, il primo fa riferimento alla directory corrente e il
+in ogni directory: il primo fa riferimento alla directory corrente e il

 secondo alla directory \textsl{genitrice} (o \textit{parent directory}) cioè
 la directory che contiene il riferimento alla directory corrente; nel caso
 secondo alla directory \textsl{genitrice} (o \textit{parent directory}) cioè
 la directory che contiene il riferimento alla directory corrente; nel caso

-questa sia la directory radice allora il riferimento è a se stessa.
+questa sia la directory radice, allora il riferimento è a se stessa.

 
 
 \subsection{I tipi di file}
 \label{sec:file_file_types}
 
 
 
 \subsection{I tipi di file}
 \label{sec:file_file_types}
 

-Come detto in precedenza in Unix esistono vari tipi di file, in Linux questi
+Come detto in precedenza in Unix esistono vari tipi di file; in Linux questi

 sono implementati come oggetti del \textit{Virtual File System} (vedi
 \secref{sec:file_vfs_work}) e sono presenti in tutti i filesystem unix-like
 utilizzabili con Linux. L'elenco dei vari tipi di file definiti dal
 sono implementati come oggetti del \textit{Virtual File System} (vedi
 \secref{sec:file_vfs_work}) e sono presenti in tutti i filesystem unix-like
 utilizzabili con Linux. L'elenco dei vari tipi di file definiti dal


@@ -143,10 +144,10 @@ dati) in base al loro contenuto, o tipo di accesso.
       un file che identifica una periferica ad accesso sequenziale \\
       \textit{block device} & \textsl{dispositivo a blocchi} &
       un file che identifica una periferica ad accesso diretto \\
       un file che identifica una periferica ad accesso sequenziale \\
       \textit{block device} & \textsl{dispositivo a blocchi} &
       un file che identifica una periferica ad accesso diretto \\

-      \textit{fifo} & \textsl{``tubo''} &
+      \textit{fifo} & \textsl{``coda''} &

       un file speciale che identifica una linea di comunicazione software
       (unidirezionale) \\
       un file speciale che identifica una linea di comunicazione software
       (unidirezionale) \\

-      \textit{socket} & \textsl{``spina''} &
+      \textit{socket} & \textsl{``presa''} &

       un file speciale che identifica una linea di comunicazione software
       (bidirezionale) \\
     \hline
       un file speciale che identifica una linea di comunicazione software
       (bidirezionale) \\
     \hline


@@ -160,27 +161,28 @@ VMS o Windows) 
 un flusso continuo di byte. Non esiste cioè differenza per come vengono visti
 dal sistema file di diverso contenuto o formato (come nel caso di quella fra
 file di testo e binari che c'è in Windows) né c'è una strutturazione a record
 un flusso continuo di byte. Non esiste cioè differenza per come vengono visti
 dal sistema file di diverso contenuto o formato (come nel caso di quella fra
 file di testo e binari che c'è in Windows) né c'è una strutturazione a record

-per il cosiddetto ``accesso diretto'' come nel caso del VMS\footnote{con i
+per il cosiddetto ``accesso diretto'' come nel caso del VMS.\footnote{con i

   kernel della serie 2.4 è disponibile una forma di accesso diretto ai dischi
   (il \textit{raw access}) attraverso dei device file appositi, che però non
   kernel della serie 2.4 è disponibile una forma di accesso diretto ai dischi
   (il \textit{raw access}) attraverso dei device file appositi, che però non

-  ha nulla a che fare con questo}.
+  ha nulla a che fare con questo.}

 
 Una seconda differenza è nel formato dei file ASCII; in Unix la fine riga è
 
 Una seconda differenza è nel formato dei file ASCII; in Unix la fine riga è

-codificata in maniera diversa da Windows o Mac, in particolare il fine
-riga è il carattere \texttt{LF} (o \verb|\n|) al posto del \texttt{CR}
-(\verb|\r|) del Mac e del \texttt{CR LF} di Windows. Questo può causare alcuni
+codificata in maniera diversa da Windows o Mac, in particolare il fine riga è
+il carattere \texttt{LF} (o \verb|\n|) al posto del \texttt{CR} (\verb|\r|)
+del Mac e del \texttt{CR LF} di Windows.\footnote{per questo esistono in Linux
+  dei programmi come \cmd{unix2dos} e \cmd{dos2unix} che effettuano una
+  conversione fra questi due formati di testo.} Questo può causare alcuni

 problemi qualora nei programmi si facciano assunzioni sul terminatore della
 riga.
 
 Si ricordi infine che in ambiente Unix non esistono tipizzazioni dei file di
 dati e che non c'è nessun supporto del sistema per le estensioni come parte
 problemi qualora nei programmi si facciano assunzioni sul terminatore della
 riga.
 
 Si ricordi infine che in ambiente Unix non esistono tipizzazioni dei file di
 dati e che non c'è nessun supporto del sistema per le estensioni come parte

-del filesystem. Ciò non ostante molti programmi adottano delle convenzioni per
+del filesystem. Ciò nonostante molti programmi adottano delle convenzioni per

 i nomi dei file, ad esempio il codice C normalmente si mette in file con
 l'estensione \file{.c}, ma questa è, per quanto usata ed accettata in maniera
 universale, solo una convenzione.
 
 
 i nomi dei file, ad esempio il codice C normalmente si mette in file con
 l'estensione \file{.c}, ma questa è, per quanto usata ed accettata in maniera
 universale, solo una convenzione.
 
 

-

 \subsection{Le due interfacce ai file}
 \label{sec:file_io_api}
 
 \subsection{Le due interfacce ai file}
 \label{sec:file_io_api}
 


@@ -203,21 +205,21 @@ rappresentati da numeri interi (cio
 L'interfaccia è definita nell'header \file{unistd.h}.
 
 La seconda interfaccia è quella che il manuale della \acr{glibc} chiama degli
 L'interfaccia è definita nell'header \file{unistd.h}.
 
 La seconda interfaccia è quella che il manuale della \acr{glibc} chiama degli

-\textit{stream}\index{stream}, essa provvede funzioni più evolute e un accesso
+\textit{stream}\index{stream}. Essa provvede funzioni più evolute e un accesso

 bufferizzato (controllato dalla implementazione fatta dalle \acr{glibc}), la
 tratteremo in dettaglio nel \capref{cha:files_std_interface}.
 
 Questa è l'interfaccia standard specificata dall'ANSI C e perciò si trova
 anche su tutti i sistemi non Unix. Gli \textit{stream} sono oggetti complessi
 e sono rappresentati da puntatori ad un opportuna struttura definita dalle
 bufferizzato (controllato dalla implementazione fatta dalle \acr{glibc}), la
 tratteremo in dettaglio nel \capref{cha:files_std_interface}.
 
 Questa è l'interfaccia standard specificata dall'ANSI C e perciò si trova
 anche su tutti i sistemi non Unix. Gli \textit{stream} sono oggetti complessi
 e sono rappresentati da puntatori ad un opportuna struttura definita dalle

-librerie del C, si accede ad essi sempre in maniera indiretta utilizzando il
+librerie del C; si accede ad essi sempre in maniera indiretta utilizzando il

 tipo \type{FILE *}.  L'interfaccia è definita nell'header \type{stdio.h}.
 
 Entrambe le interfacce possono essere usate per l'accesso ai file come agli
 altri oggetti del VFS (pipe, socket, device, sui quali torneremo in dettaglio
 a tempo opportuno), ma per poter accedere alle operazioni di controllo su un
 qualunque tipo di oggetto del VFS occorre usare l'interfaccia standard di Unix
 tipo \type{FILE *}.  L'interfaccia è definita nell'header \type{stdio.h}.
 
 Entrambe le interfacce possono essere usate per l'accesso ai file come agli
 altri oggetti del VFS (pipe, socket, device, sui quali torneremo in dettaglio
 a tempo opportuno), ma per poter accedere alle operazioni di controllo su un
 qualunque tipo di oggetto del VFS occorre usare l'interfaccia standard di Unix

-coi \textit{file descriptor}. Allo stesso modo devono essere usati i
+con i \textit{file descriptor}. Allo stesso modo devono essere usati i

 \textit{file descriptor} se si vuole ricorrere a modalità speciali di I/O come
 il polling o il non-bloccante (vedi \capref{cha:file_advanced}).
 
 \textit{file descriptor} se si vuole ricorrere a modalità speciali di I/O come
 il polling o il non-bloccante (vedi \capref{cha:file_advanced}).