X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=blobdiff_plain;f=filedir.tex;h=f6ad01f2cae55b035e4e20934db05fe9326b4182;hb=e603c6e45f005839118e2142839114c00efa3449;hp=b7192d5e16826717298b844964f100f8716f5865;hpb=68f626be4f8d5c0816b9b552f744f05f0d72c8dc;p=gapil.git

diff --git a/filedir.tex b/filedir.tex
index b7192d5..f6ad01f 100644
--- a/filedir.tex
+++ b/filedir.tex
@@ -147,7 +147,7 @@ l'\textit{effective group id} e gli eventuali \textit{supplementary group id}
 del processo.
 
 Per una spiegazione dettagliata degli identificatori associati ai processi si
-veda \secref{sec:prochand_perms}; normalmente, a parte quanto vedremo in
+veda \secref{sec:proc_perms}; normalmente, a parte quanto vedremo in
 \secref{sec:file_suid_sgid}, l'\textit{effective user id} e
 l'\textit{effective group id} corrispondono a uid e gid dell'utente che ha
 lanciato il processo, mentre i \textit{supplementary group id} sono quelli dei
@@ -214,7 +214,7 @@ alcune propriet
 \textit{set-group-ID bit}) che sono identificati dalle constanti
 \macro{S\_ISUID} e \macro{S\_ISGID}.
 
-Come spiegato in dettaglio in \secref{sec:prochand_exec}, quando si lancia un
+Come spiegato in dettaglio in \secref{sec:proc_exec}, quando si lancia un
 programma il comportamendo normale del kernel è quello di settare
 l'\textit{effective user id} e l'\textit{effective group id} del nuovo
 processo all'uid e al gid del processo corrente, che normalmente corrispondono
@@ -241,7 +241,7 @@ Chiaramente avere un processo che ha privilegi superiori a quelli che avrebbe
 normalmente l'utente che lo ha lanciato comporta vari rischi, e questo tipo di
 programmi devono essere scritti accuratamente per evitare che possano essere
 usati per guadagnare privilegi non consentiti (torneremo sull'argomento in
-\secref{sec:prochand_perms}).
+\secref{sec:proc_perms}).
 
 La presenza dei bit \acr{suid} e \acr{sgid} su un file può essere
 rilevata con il comando \cmd{ls -l}, in tal caso comparirà la lettera \cmd{s}
@@ -352,7 +352,7 @@ un file viene fatto usando \textit{effective user id} e \textit{effective
   group id} del processo, ma ci sono casi in cui si può voler effettuare il
 controllo usando il \textit{real user id} e il \textit{real group id} (cioè
 l'uid dell'utente che ha lanciato il programma, che, come accennato in
-\secref{sec:file_suid_sgid} e spiegato in \secref{sec:prochand_perms} non è
+\secref{sec:file_suid_sgid} e spiegato in \secref{sec:proc_perms} non è
 detto sia uguale all'\textit{effective user id}). Per far questo si può usare
 la funzione \func{access}, il cui prototipo è:
 
@@ -699,7 +699,7 @@ Dato che il valore numerico pu
 standard POSIX definisce un insieme di macro per verificare il tipo di files,
 queste vengono usate anche da Linux che supporta pure le estensioni per link
 simbolici e socket definite da BSD, l'elenco completo di tutte le macro
-definite in GNU/Linux è riportato in \ntab:
+definite in GNU/Linux è riportato in \ntab.
 \begin{table}[htb]
   \centering
   \footnotesize
@@ -1356,7 +1356,7 @@ Un secondo punto da tenere presente 
 anche ad un file che non esiste; ad esempio possiamo creare un file temporaneo
 nella nostra directory con un link del tipo:
 \begin{verbatim}
-$ln -s /tmp/tmp_file temporaneo
+$ ln -s /tmp/tmp_file temporaneo
 \end{verbatim}%$
 ma anche se \file{/tmp/tmp\_file} non esiste. Aprendo in scrittura
 \file{temporaneo} questo verrà scritto; ma se cercassimo di accederlo in sola
@@ -1420,6 +1420,9 @@ la funzione \texttt{opendir} apre uno di questi stream e la funzione
 parlavamo in \secref{sec:file_vfs}) in una opportuna struttura
 \texttt{struct dirent}.
 
+(NdA Il resto va scritto!!! É noioso e lo farò più avanti).
+
+
 
 \subsection{La directory di lavoro}
 \label{sec:file_work_dir}
@@ -1467,7 +1470,7 @@ Di questa funzione esiste una versione \texttt{char * getwd(char * buffer)}
 fatta per compatibilità all'indietro con BSD, che non consente di specificare
 la dimensione del buffer; esso deve essere allocato in precedenza ed avere una
 dimensione superiore a \texttt{PATH\_MAX} (di solito 256 bytes, vedi
-\secref{sec:xxx_limits}; il problema è che in Linux non esiste una dimensione
+\secref{sec:xxx_limits}); il problema è che in Linux non esiste una dimensione
 superiore per un pathname, per cui non è detto che il buffer sia sufficiente a
 contenere il nome del file, e questa è la ragione principale per cui questa
 funzione è deprecata.