Sanitizzazione nome delle funzioni degli esempi, e dei relativi file e
[gapil.git] / intro.tex
index 97c26bce81ea96bf977c2cab0bc0e3a1b5eaf391..7378e59805390b7bad00ca6b1a82598e822d16e3 100644 (file)
--- a/intro.tex
+++ b/intro.tex
@@ -495,22 +495,26 @@ chiamato il suo \textit{pathname},\footnote{il manuale della \acr{glibc}
   di \textit{filename} e di componente per il nome del file all'interno della
   directory. Non seguiremo questa scelta dato che l'uso della parola
   \textit{pathname} è ormai così comune che mantenerne l'uso è senz'altro più
-  chiaro dell'alternativa proposta.} vale a dire tramite il percorso che si
-deve fare per accedere al file a partire da una certa ``\textit{directory}''.
+  chiaro dell'alternativa proposta.} vale a dire tramite il
+``\textsl{percorso}'' (nome che talvolta viene usato come traduzione di
+\textit{pathname}) che si deve fare per accedere al file a partire da una
+certa ``\textit{directory}''.
 
-Una directory in realta è anch'essa un file, nel senso che è anch'essa un
+Una directory in realtà è anch'essa un file, nel senso che è anch'essa un
 oggetto di un filesystem, solo che è un file particolare che il kernel
 riconosce appositamente come tale per poterlo utilizzare come directory. Il
 suo scopo è quello di contenere una lista di nomi di file e le informazioni
-che associano ciascuno di questi nomi al relativo contenuto.
+che associano ciascuno di questi nomi al relativo contenuto (torneremo su
+questo in sez.~\ref{sec:file_arch_func}).
 
 Dato che questi nomi possono corrispondere ad un qualunque altro oggetto del
 filesystem, compresa un'altra directory, si ottiene naturalmente
 un'organizzazione ad albero inserendo nomi di directory dentro altre
 directory.  All'interno dello stesso albero si potranno poi inserire anche
-tutti gli altri oggetti previsti l'interfaccia del VFS (su cui torneremo in
-sez.~\ref{sec:file_file_types}), come le fifo, i link, i socket e gli stessi
-\index{file!di~dispositivo} file di dispositivo.
+tutti gli altri oggetti previsti l'interfaccia del
+\itindex{Virtual~File~System} VFS (su cui torneremo in
+sez.~\ref{sec:file_file_types}), come le fifo, i collegamenti simbolici, i
+socket e gli stessi \index{file!di~dispositivo} file di dispositivo.
 
 La convenzione usata nei sistemi unix-like per indicare i \textit{pathname}
 dei file è quella di usare il carattere ``\texttt{/}'' come separatore fra i
@@ -522,31 +526,42 @@ sta in cima all'albero, essa viene indicata semplicemente con il
 
 Un file può essere indicato rispetto ad una directory semplicemente
 specificandone il nome, il manuale della \acr{glibc} chiama i nomi contenuti
-nelle directory \textsl{componenti} (in inglese \textit{file name
-  components}), noi li chiameremo più semplicemente \textsl{nomi} o
-\textsl{voci}. Il procedimento con cui dato un \textit{pathname} si individua
-il file a cui esso fa riferimento è chiamato risoluzione del nome
-(\textit{filename 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 il carattere ``\texttt{/}'' come separatore. Nel caso si indichi un
-nome vuoto il costrutto ``\texttt{//}'' viene considerato equivalente a
-``\texttt{/}''. Ovviamente perché il procedimento funzioni occorre che i nomi
-indicati come directory esistano e siano effettivamente directory, inoltre i
-permessi (si veda sez.~\ref{sec:file_access_control}) devono consentire
-l'accesso all'intero \textit{pathname}.
+nelle directory ``componenti'' (in inglese \textit{file name components}), noi
+li chiameremo più semplicemente \textsl{nomi} o \textsl{voci}, riservando la
+parola \textsl{componenti} ai nomi che, separati da una ``\texttt{/}'',
+costituiscono il \textit{pathname}. Questi poi dovranno corrispondere, perché
+il \textit{pathname} sia valido, a voci effettivamente presenti nelle
+directory, ma non è detto che un \textit{pathname} debba per forza risultare
+valido.  
+
+Il procedimento con cui dato un \textit{pathname} si individua il file a cui
+esso fa riferimento, è chiamato \textsl{risoluzione del percorso}
+(\textit{filename resolution} o \textit{pathname resolution}). Lo stesso
+procedimento ci può anche dire che il \textit{pathname} usato non è valido.
+La risoluzione viene eseguita esaminando il \textit{pathname} da sinistra a
+destra e localizzando ogni componente dello stesso come nome in una directory
+a partire dalla directory iniziale, usando il carattere ``\texttt{/}'' come
+separatore per scendere dall'una all'altra. Nel caso si indichi un componente
+vuoto il costrutto ``\texttt{//}'' viene considerato equivalente a
+``\texttt{/}''.
+
+Ovviamente perché la risoluzione abbia successo occorre che i componenti
+intermedi esistano e siano effettivamente directory, e che il file o la
+directory indicata dall'ultimo componente esista.  Inoltre i permessi relativi
+alle directory indicate nel \textit{pathname} (torneremo su questo
+sez.~\ref{sec:file_access_control}) dovranno consentire l'accesso all'intero
+\textit{pathname}.
 
 Se il \textit{pathname} comincia con il carattere ``\texttt{/}'' la ricerca
 parte dalla directory radice del processo. Questa, a meno di non avere
 eseguito una \func{chroot} (funzione su cui torneremo in
 sez.~\ref{sec:file_chroot}) è la stessa per tutti i processi ed equivale alla
-directory radice dell'albero dei file; in questo caso si parla di un
-\textsl{pathname assoluto} \itindsub{pathname}{assoluto}.  Altrimenti la
-ricerca parte dalla \index{directory~di~lavoro} directory di lavoro corrente
-del processo (su cui torneremo in sez.~\ref{sec:file_work_dir}) ed il
-\textit{pathname} è detto \itindsub{pathname}{relativo} \textsl{pathname
-  relativo}.
+directory radice dell'albero dei file montata dal kernel all'avvio del
+sistema; in questo caso si parla di un \textsl{pathname assoluto}
+\itindsub{pathname}{assoluto}.  Altrimenti la ricerca parte dalla
+\index{directory~di~lavoro} directory di lavoro corrente del processo (su cui
+torneremo in sez.~\ref{sec:file_work_dir}) ed il \textit{pathname} è detto
+\itindsub{pathname}{relativo} \textsl{pathname relativo}.
 
 Infine i nomi di directory ``\file{.}'' e ``\file{..}'' hanno un significato
 speciale e vengono inseriti in ogni directory quando questa viene creata (vedi
@@ -556,11 +571,11 @@ corrente e il secondo alla directory \textsl{genitrice} (o \textit{parent
 corrente.
 
 In questo modo con ``\file{..}'' si può usare un \itindsub{pathname}{relativo}
-pathname relativo per indicare un file posto al di sopra della directory
-corrente, tornando all'indietro nell'albero dei file.  Questa retromarcia però
-su fermerà una volta raggiunta la directory radice, perché non esistendo in
-questo caso una directory superiore, il nome ``\file{..}''  farà riferimento
-alla radice stessa.
+\textit{pathname} relativo per indicare un file posto al di sopra della
+directory corrente, tornando all'indietro nell'albero dei file.  Questa
+retromarcia però su fermerà una volta raggiunta la directory radice, perché
+non esistendo in questo caso una directory superiore, il nome ``\file{..}''
+farà riferimento alla radice stessa.
 
 \itindend{pathname}
 \itindend{pathname~resolution}
@@ -868,7 +883,7 @@ infinita serie di problemi di portabilità.
                       sez.~\ref{sec:ipc_sysv_generic}).\\
     \type{loff\_t}  & Posizione corrente in un file.\\
     \type{mode\_t}  & Attributi di un file.\\
-    \type{nlink\_t} & Contatore dei link su un file.\\
+    \type{nlink\_t} & Contatore dei collegamenti su un file.\\
     \type{off\_t}   & Posizione corrente in un file.\\
     \type{pid\_t}   & Identificatore di un processo (vedi
                       sez.~\ref{sec:proc_pid}).\\
@@ -958,7 +973,7 @@ della AT\&T.
 
 Benché BSD non sia mai stato uno standard formalizzato, l'implementazione
 dello Unix dell'Università di Berkeley nella sua storia ha introdotto una
-serie di estensioni e interfacce di grandissima rilevanza, come i link
+serie di estensioni e interfacce di grandissima rilevanza, come i collegamenti
 simbolici, la funzione \code{select} ed i socket di rete. Per questo motivo si
 fa spesso riferimento esplicito alle interfacce presenti nelle varie versioni
 dello Unix di Berkeley con una apposita sigla.