La rimozione di un file (o più precisamente della voce che lo referenzia
all'interno di una directory) si effettua con la funzione \func{unlink}; il
suo prototipo è il seguente:
-
\begin{prototype}{unistd.h}{int unlink(const char * pathname)}
Cancella il nome specificato dal pathname nella relativa directory e
decrementa il numero di riferimenti nel relativo inode. Nel caso di link
per cancellare un file o una directory (e funziona anche per i sistemi che non
supportano i link diretti). Per i file è identica a \func{unlink} e per le
directory è identica a \func{rmdir}:
-
\begin{prototype}{stdio.h}{int remove(const char *pathname)}
Cancella un nome dal filesystem. Usa \func{unlink} per i file e
\func{rmdir} per le directory.
nello stesso filesystem) si usa invece la funzione \func{rename}\footnote{la
funzione è definita dallo standard ANSI C solo per i file, POSIX estende la
funzione anche alle directory}, il cui prototipo è:
-
\begin{prototype}{stdio.h}
{int rename(const char *oldpath, const char *newpath)}
link simbolico comporta l'applicazione della funzione al file da esso
specificato. La funzione che permette di creare un nuovo link simbolico è
\func{symlink}; il suo prototipo è:
-
\begin{prototype}{unistd.h}
{int symlink(const char * oldpath, const char * newpath)}
Crea un nuovo link simbolico di nome \func{newpath} il cui contenuto è
alle informazioni del link invece che a quelle del file a cui esso fa
riferimento. Quando si vuole leggere il contenuto di un link simbolico si usa
la funzione \func{readlink}, il cui prototipo è:
-
\begin{prototype}{unistd.h}
{int readlink(const char * path, char * buff, size\_t size)}
Legge il contenuto del link simbolico indicato da \var{path} nel buffer
omonime degli analoghi comandi di shell. Per poter accedere ai tipi usati
da queste funzioni si deve includere il file \file{sys/types.h}, il
prototipo della prima è:
-
\begin{prototype}{sys/stat.h}
{int mkdir (const char * dirname, mode\_t mode)}
Crea una nuova directory vuota con il nome indicato da \var{dirname},
La seconda funzione serve ad eliminare una directory già vuota (la directory
deve cioè contenere soltanto le due voci standard \file{.} e \file{..}); il
suo prototipo è:
-
\begin{prototype}{sys/stat.h}
{int rmdir (const char * dirname)} Cancella la directory \var{dirname}, che
deve essere vuota. Il nome può essere indicato con il pathname assoluto o
In genere il kernel tiene traccia per ciascun processo dell'inode della
directory di lavoro corrente, per ottenere il pathname occorre usare una
apposita funzione di libreria, \func{getcwd}, il cui prototipo è:
-
\begin{prototype}{unistd.h}{char * getcwd (char * buffer, size\_t size)}
Restituisce il filename completo della directory di lavoro corrente nella
stringa puntata da \var{buffer}, che deve essere precedentemente
lavoro corrente. Dato che anche le directory sono file, è possibile riferirsi
ad esse anche tramite il file descriptor dell'interfaccia a basso livello, e
non solo tramite il filename, i prototipi di queste funzioni sono:
-
\begin{functions}
\headdecl{unistd.h}
\funcdecl{int chdir (const char * path)}
I tempi di ultimo accesso e modifica possono essere cambiati usando la
funzione \func{utime}, il cui prototipo è:
-
\begin{prototype}{utime.h}
{int utime(const char * filename, struct utimbuf *times)}
\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 è:
-
\begin{prototype}{unistd.h}
{int access(const char *pathname, int mode)}
esecuzione non comporta che contenga un programma eseguibile. La funzione
ritorna zero solo se tutte i permessi controllati sono disponibili, in caso
contrario (o di errore) ritorna -1.
-
\begin{table}[htb]
\centering
\footnotesize
In questa sezione faremo una breve introduzione sulla architettura su cui è
basata dell'interfaccia dei \textit{file descriptor}, che, sia pure con
differenze di implementazione, è comune ad ogni implementazione di unix.
-Vedremo cosa comporti questa architettura in caso di accesso contemporaneo ai
-file da parte di più processi.
-\subsection{L'architettura dei \textit{file descriptors}}
+\subsection{L'architettura dei \textit{file descriptor}}
\label{sec:file_fd}
Per poter accedere al contenuto di un file occorre creare un canale di
ogni ulteriore operazione.
All'interno di ogni processo i file aperti sono identificati da un intero non
-negativo, chiamato appunto \textit{file descriptors}, quando un file viene
+negativo, chiamato appunto \textit{file descriptor}, quando un file viene
aperto la funzione restituisce il file descriptor, e tutte le successive
operazioni devono passare il \textit{file descriptors} come argomento.
ed un elenco dei file aperti nella \textit{file table}.
La \textit{process table} è una tabella che contiene una voce per ciascun
-processo attivo nel sistema. In Linux la tabella è costituita da strutture di
-tipo \var{task\_struct} nelle quali sono raccolte tutte le informazioni
-relative ad un singolo processo; fra queste informazioni c'è anche il
-puntatore ad una ulteriore struttura di tipo \var{files\_struct} in cui sono
+processo attivo nel sistema. In Linux ciascuna voce è costituita da una
+struttura di tipo \var{task\_struct} nella quale sono raccolte tutte le
+informazioni relative al processo; fra queste informazioni c'è anche il
+puntatore ad una ulteriore struttura di tipo \var{files\_struct}, in cui sono
contenute le informazioni relative ai file che il processo ha aperto, ed in
particolare:
\begin{itemize*}
\textit{file table} per ogni file aperto.
\end{itemize*}
il \textit{file descriptor} in sostanza è l'intero positivo che indicizza
-questa tabella.
+quest'ultima tabella.
La \textit{file table} è una tabella che contiene una voce per ciascun file
che è stato aperto nel sistema. In Linux è costituita da strutture di tipo
file, fra cui:
\begin{itemize*}
\item lo stato del file (nel campo \var{f\_flags}).
-\item il valore della posizione corrente (l'\textit{offset}) nel file.
+\item il valore della posizione corrente (l'\textit{offset}) nel file (nel
+ campo \var{f\_pos}).
\item un puntatore all'inode\footnote{nel kernel 2.4.x si è in realtà passati
ad un puntatore ad una struttura \var{dentry} che punta a sua volta
all'inode passando per la nuova struttura del VFS} del file.
numero di file aperti era anche soggetto ad un limite massimo dato dalle
dimensioni del vettore di puntatori con cui era realizzata la tabella dei file
descriptor dentro \var{file\_struct}; questo limite intrinseco non sussiste
-più, dato che si è passati ad una linked list, restano i limiti imposti
-dall'amministratore (vedi \secref{sec:sys_limits}).
+più, dato che si è passati da un vettore ad una linked list, ma restano i
+limiti imposti dall'amministratore (vedi \secref{sec:sys_limits}).
La funzione apre il file, usando il primo file descriptor libero, e crea
l'opportuna voce (cioè la struttura \var{file}) nella file table. Viene usato
-sempre il file descriptor con il valore più basso, questa caratteritica
+sempre il file descriptor con il valore più basso, questa caratteristica
permette di prevedere qual'è il valore che si otterrà e viene talvolta usata
da alcune applicazioni per sostituire i file corrispondenti ai file standard
di \secref{sec:file_std_descr}: se ad esempio si chiude lo standard input e si
\secref{sec:proc_exec}) ed l'offset è settato all'inizio del file.
Il parametro \var{mode} specifica i permessi con cui il file viene
-eventualmente creato; i valori possibili gli stessi già visti in
+eventualmente creato; i valori possibili sono gli stessi già visti in
\secref{sec:file_perm_overview} e possono essere specificati come OR binario
delle costanti descritte in \tabref{tab:file_bit_perm}. Questi permessi
-filtrati dal valore di \file{umask} per il processo.
+filtrati dal valore di \file{umask} (vedi \secref{sec:file_umask}) per il
+processo.
La funzione prevede diverse opzioni, che vengono specificate usando vari bit
-del parametro \var{flags}. Alcuni di questi vanno anche a costituire lo il
+del parametro \var{flags}. Alcuni di questi bit vanno anche a costituire il
flag di stato del file (o \textit{file status flag}), che è mantenuto nel
-campo \var{f\_flags} della struttura \var{file} (vedi \curfig). Questi
-bit sono divisi in tre categorie principali:
+campo \var{f\_flags} della struttura \var{file} (al solito si veda lo schema
+di \curfig). Essi sono divisi in tre categorie principali:
\begin{itemize}
\item \textsl{i bit delle modalità di accesso}: specificano con quale modalità
- si accede al file: i valori possibili sono lettura, scrittura o
+ si accederà al file: i valori possibili sono lettura, scrittura o
lettura/scrittura. Uno di questi bit deve essere sempre specificato quando
si apre un file. Vengono settati alla chiamata da \func{open}, e possono
essere riletti con una \func{fcntl} (fanno parte del \textit{file status
flag}), ma non modificati.
\item \textsl{i bit delle modalità di apertura}: permettono di specificare
- alcuni dei modi di funzionamento di \func{open}. Hanno effetto solo al
- momento della chiamata della funzione e non sono memorizzati nè possono
- essere riletti.
+ alcune delle caratteristiche del comportamento di \func{open} quando viene
+ eseguita. Hanno effetto solo al momento della chiamata della funzione e non
+ sono memorizzati nè possono essere riletti.
\item \textsl{i bit delle modalità di operazione}: permettono di specificare
- alcuni effetti validi anche in seguito per il comportamento delle operazioni
- sul file (come la \func{read} o la \func{write}). Anch'essi fanno parte del
+ alcune caratteristiche del comportamento delle future operazioni sul file
+ (come la \func{read} o la \func{write}). Anch'essi fanno parte del
\textit{file status flag}. Il loro valore è settato alla chiamata di
- \func{open}, ma possono essere riletti e modificati con una \func{fcntl}.
+ \func{open}, ma possono essere riletti e modificati (insieme alle
+ caratteristiche operative che controllano) con una \func{fcntl}.
\end{itemize}
In \ntab\ si sono riportate, ordinate e divise fra loro secondo le tre
-modalità appena elencate, le costanti che identificano i vari bit, queste
-possono essere combinate con un OR aritmetico per costruire il valore del
+modalità appena elencate, le costanti mnemoniche associate a ciascuno di
+questi bit, dette costanti possono essere combinate fra di loro con un OR
+aritmetico per costruire il valore (in forma di maschera binaria) del
parametro \var{flags} da passare alla \func{open} per specificarne il
comportamento.
\end{table}
Nelle prime versioni di unix i flag specificabili per \func{open} erano solo
-quelli delle modalità di apertura. Per questo motivo per creare un file c'era
-una system call apposita, \func{creat}, il cui prototipo è:
+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 è:
\begin{prototype}{fcntl.h}
{int creat(const char *pathname, mode\_t mode)}
-%%
+%%
%% GaPiL : Guida alla Programmazione in Linux
%%
%% S. Piccardi Oct. 2000
%\includeonly{macro,pref,intro,fdl}
-\title{\Huge \textbf{GaPiL}\\
-Guida alla Programmazione in Linux.}
+\title{\Huge \textbf{\textsl{G}a\textsl{P}i\textsl{L}}\\
+\huge Guida alla Programmazione in Linux.}
\author{Simone Piccardi}
\section{Gli standard di unix e GNU/Linux}
\label{sec:intro_standard}
-In questa sezione prenderemo in esame alcune caratteristiche generali del
-sistema e gli standard adottati per le funzioni, i prototipi, gli errori, i
-tipi di dati.
-
-\subsection{Prototipi e puntatori}
-\label{sec:intro_function}
-
+In questa sezione prenderemo faremo una breve panoramica yrelativi ai vari
+standard che nel tempo sono stati formalizzati da enti, associazioni, e
+organizzazioni varie riguardanti interfacce di programmazioni e
+caratteristiche di un sistema unix-like.
\subsection{Lo standard ANSI C}
\label{sec:intro_ansiC}
suddivisa la libreria. In \ntab\ si sono riportati questi header, insieme a
quelli definiti negli altri standard descritti nelle sezioni successive.
-\subsection{Lo standard POSIX}
+\subsection{Lo standard IEEE -- POSIX}
\label{sec:intro_posix}
In realtà POSIX è una famiglia di standard diversi, il nome, suggerito da
\subsection{Lo standard X/Open -- XPG3}
\label{sec:intro_xopen}
-Il consorzio X/Open nacque come consorzio di venditori di sistemi unix, che
-nel 1989 produsse una voluminosa guida chiamata \textit{X/Open Portability
- Guide, Issue 3} al cui interno definiva una ulteriore standardizzazione
-dell'interfaccia ad un sistema unix.
+Il consorzio X/Open nacque nel 1984 come consorzio di venditori di sistemi
+unix per giungere ad una armonizzazione dele varie implementazioni di unix.
+Per far questo iniziò a pubblicare una serie di documentazioni e specifiche
+sotto il nome di \textit{X/Open Portability Guide} (che chiameremo XPGn).
+
+
+Nel 1989 produsse una terza versione della sua guida particolarmente
+voluminosa (la \textit{X/Open Portability Guide, Issue 3}), che venne presa
+come riferimento da vari produttori, e al cui interno definiva una ulteriore
+standardizzazione dell'interfaccia ad un sistema unix.
Questo standard, detto anche XPG3 dal nome della suddetta guida, è sempre
-basato sullo standard POSIX.1, ma prevede una serie di funzionalità
-aggiuntive.
+basato sullo standard POSIX.1, ma prevede una serie di funzionalità aggiuntive
+fra cui le specifiche delle API per l'interfaccia grafica (X11).
+
+Nel 1992 lo standard venne rivisto con una nuova versione della guida (XPG4)
+che aggiungeva l'interfaccia XTI (\textit{X transport Interface}) mirante a
+soppiantare (senza molto successo) quella l'interfaccia dei socket derivata da
+BSD.
+
-Il consorzio
+\subsection{Gli standard UNIX -- Open Group}
+\label{sec:intro_opengroup}
+
+Nel 1993 il marchi Unix passò di proprietà dalla Novell (che a sua volta lo
+aveva comprato dalla AT\&T) al consorzio X/Open, che iniziò a pubblicare le
+sue specifiche sotto il nome di \textit{Single UNIX Specification},
+
+
+
+
+
+\subsection{Prototipi e puntatori}
+\label{sec:intro_function}
\subsection{Tipi di dati primitivi}
%
\newenvironment{prototype}[2]
{% defining what is done by \begin
+ \par
\center
\footnotesize
\begin{minipage}[c]{14cm}
\newcommand{\funcdecl}[1]{\item\texttt{#1}\par}
\newenvironment{functions}
{% defining what is done by \begin
+ \par
\footnotesize
\center
\begin{minipage}[c]{14cm}
projects / gapil.git / commitdiff