Correzioni varie piu qualce notizia in piu` sugli standard

diff --git a/filedir.tex b/filedir.tex
index 19f347dddcf1bcc312bd0ba7da98f455bd8ff347..b985da195568042040b81c218dc8ef698f2cae92 100644 (file)
--- a/filedir.tex
+++ b/filedir.tex
@@ -108,7 +108,6 @@ funzione restituisce l'errore \macro{EPERM}.
 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:
 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
 \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


@@ -173,7 +172,6 @@ funzione \func{remove}. Questa 
 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}:
 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.
 \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.


@@ -187,7 +185,6 @@ Per cambiare nome ad un file o a una directory (che devono comunque essere
 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 è:
 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)} 
   
 \begin{prototype}{stdio.h}
   {int rename(const char *oldpath, const char *newpath)} 
   


@@ -276,7 +273,6 @@ funzioni di libreria (come \func{open} o \func{stat}) dare come parametro un
 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 è:
 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 è
 \begin{prototype}{unistd.h}
   {int symlink(const char * oldpath, const char * newpath)} 
   Crea un nuovo link simbolico di nome \func{newpath} il cui contenuto è


@@ -355,7 +351,6 @@ Dato che, come indicato in \tabref{tab:file_symb_effect}, funzioni come la
 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 è:
 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
 \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


@@ -436,7 +431,6 @@ Queste due funzioni servono per creare e cancellare delle directory e sono
 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 è:
 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},
 \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},


@@ -474,7 +468,6 @@ titolarit
 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 è:
 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
 \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


@@ -548,7 +541,6 @@ directory corrente di qualunque comando da essa lanciato.
 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 è:
 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
 \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


@@ -600,7 +592,6 @@ nome (che deriva da \textit{change directory}), per cambiare la directory di
 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:
 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)} 
 \begin{functions}
   \headdecl{unistd.h} 
   \funcdecl{int chdir (const char * path)} 


@@ -1014,7 +1005,6 @@ esiste.
 
 I tempi di ultimo accesso e modifica possono essere cambiati usando la
 funzione \func{utime}, il cui prototipo è:
 
 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)} 
 
 \begin{prototype}{utime.h}
 {int utime(const char * filename, struct utimbuf *times)} 
 


@@ -1393,7 +1383,6 @@ l'\acr{uid} dell'utente che ha lanciato il programma, che, come accennato in
 \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 è:
 \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)}
 
 \begin{prototype}{unistd.h}
 {int access(const char *pathname, int mode)}
 


@@ -1420,7 +1409,6 @@ possa scrivere come in un file, e il fatto che un file abbia permesso di
 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.
 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
 \begin{table}[htb]
   \centering
   \footnotesize

diff --git a/fileunix.tex b/fileunix.tex
index 9f021143a7980fc473137d7a8ea88bd540987dd6..5734c43c02e99db3ba6261315b1da465ea94597a 100644 (file)
--- a/fileunix.tex
+++ b/fileunix.tex
@@ -16,11 +16,9 @@ ANSI C.
 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.
 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
 \label{sec:file_fd}
 
 Per poter accedere al contenuto di un file occorre creare un canale di


@@ -33,7 +31,7 @@ dovr
 ogni ulteriore operazione.
 
 All'interno di ogni processo i file aperti sono identificati da un intero non
 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.
 
 aperto la funzione restituisce il file descriptor, e tutte le successive
 operazioni devono passare il \textit{file descriptors} come argomento.
 


@@ -43,10 +41,10 @@ sempre un elenco dei processi attivi nella cosiddetta \textit{process table}
 ed un elenco dei file aperti nella \textit{file table}.
 
 La \textit{process table} è una tabella che contiene una voce per ciascun
 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*}
 contenute le informazioni relative ai file che il processo ha aperto, ed in
 particolare:
 \begin{itemize*}


@@ -56,7 +54,7 @@ particolare:
   \textit{file table} per ogni file aperto.
 \end{itemize*}
 il \textit{file descriptor} in sostanza è l'intero positivo che indicizza
   \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
 
 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


@@ -64,7 +62,8 @@ che 
 file, fra cui:
 \begin{itemize*}
 \item lo stato del file (nel campo \var{f\_flags}).
 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.
 \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.


@@ -142,8 +141,8 @@ Nelle vecchie versioni di unix (ed anche in Linux fino al kernel 2.0.x) il
 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
 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}).

 
 
 
 
 
 


@@ -207,7 +206,7 @@ prototipo 
 
 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
 
 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
 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


@@ -221,37 +220,40 @@ restare aperto attraverso una \func{exec} (come accennato in
 \secref{sec:proc_exec}) ed l'offset è settato all'inizio del file. 
 
 Il parametro \var{mode} specifica i permessi con cui il file viene
 \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
 \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
 
 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
 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à
 \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
   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
 \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
   \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
 \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.
 
 parametro \var{flags} da passare alla \func{open} per specificarne il
 comportamento.
 


@@ -344,8 +346,9 @@ comportamento.
 \end{table}
 
 Nelle prime versioni di unix i flag specificabili per \func{open} erano solo
 \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)}
 
 \begin{prototype}{fcntl.h}
   {int creat(const char *pathname, mode\_t mode)}

diff --git a/gapil.tex b/gapil.tex
index 1007fbc7cb5a11f37a2ec340dc0b3f03c2cb8b53..b7e32c34a8db89826bb625becaf43f7baf36ef42 100644 (file)
--- a/gapil.tex
+++ b/gapil.tex
@@ -1,4 +1,4 @@
-%%
+%% 

 %% GaPiL : Guida alla Programmazione in Linux
 %%
 %% S. Piccardi Oct. 2000 
 %% GaPiL : Guida alla Programmazione in Linux
 %%
 %% S. Piccardi Oct. 2000 


@@ -36,8 +36,8 @@
 
 %\includeonly{macro,pref,intro,fdl}
 
 
 %\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}
 
 
 \author{Simone Piccardi}
 

diff --git a/intro.tex b/intro.tex
index 6e6fe60f5d13b01038d7627e28955375f0f63436..cd878bf60b6361f6ffbfa667dd6cf3c9d6042f87 100644 (file)
--- a/intro.tex
+++ b/intro.tex
@@ -236,13 +236,10 @@ disattivati\footnote{i controlli infatti vengono sempre eseguiti da un codice
 \section{Gli standard di unix e GNU/Linux}
 \label{sec:intro_standard}
 
 \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}
 
 \subsection{Lo standard ANSI C}
 \label{sec:intro_ansiC}


@@ -264,7 +261,7 @@ quindici header files, uno per ciascuna delle quindici aree in cui 
 suddivisa la libreria. In \ntab\ si sono riportati questi header, insieme a
 quelli definiti negli altri standard descritti nelle sezioni successive.
 
 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
 \label{sec:intro_posix}
 
 In realtà POSIX è una famiglia di standard diversi, il nome, suggerito da


@@ -290,16 +287,40 @@ internazionale con la sigla ISO/IEC 9945-1:1990.
 \subsection{Lo standard X/Open -- XPG3}
 \label{sec:intro_xopen}
 
 \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
 
 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}
 
 
 \subsection{Tipi di dati primitivi}

diff --git a/macro.tex b/macro.tex
index 05509cc0c8c35326a0a3568161467778fa5b2f84..ad70c83526b2b595568ac88d24dae70bd57b87b8 100644 (file)
--- a/macro.tex
+++ b/macro.tex
@@ -66,6 +66,7 @@ tab.~\thechapter.\theusercount}
 %
 \newenvironment{prototype}[2]
 {% defining what is done by \begin
 %
 \newenvironment{prototype}[2]
 {% defining what is done by \begin

+  \par

   \center
   \footnotesize
   \begin{minipage}[c]{14cm}
   \center
   \footnotesize
   \begin{minipage}[c]{14cm}


@@ -97,6 +98,7 @@ tab.~\thechapter.\theusercount}
 \newcommand{\funcdecl}[1]{\item\texttt{#1}\par}
 \newenvironment{functions}
 {% defining what is done by \begin
 \newcommand{\funcdecl}[1]{\item\texttt{#1}\par}
 \newenvironment{functions}
 {% defining what is done by \begin

+  \par

   \footnotesize
   \center
     \begin{minipage}[c]{14cm}
   \footnotesize
   \center
     \begin{minipage}[c]{14cm}