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
-\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
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
-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}
-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
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) \\
- \textit{socket} & \textsl{``spina''} &
+ \textit{socket} & \textsl{``presa''} &
un file speciale che identifica una linea di comunicazione software
(bidirezionale) \\
\hline
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
- 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 è
-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
-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.
-
\subsection{Le due interfacce ai file}
\label{sec:file_io_api}
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
-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
-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}).
projects / gapil.git / blobdiff