Inizio revisione capitolo sessioni e terminali
authorSimone Piccardi <piccardi@gnulinux.it>
Sun, 8 Jul 2012 20:51:08 +0000 (20:51 +0000)
committerSimone Piccardi <piccardi@gnulinux.it>
Sun, 8 Jul 2012 20:51:08 +0000 (20:51 +0000)
session.tex

index 6fd9027748b84088c909196cb9eaf839571b4ac1..8c06fd950bbfc3cb45f2f406fffd30624925ce55 100644 (file)
@@ -9,7 +9,7 @@
 %% License".
 %%
 
-\chapter{Interfaccia utente: terminali e sessioni di lavoro}
+\chapter{Terminali e sessioni di lavoro}
 \label{cha:session}
 
 
@@ -44,10 +44,10 @@ Originariamente si trattava di dispositivi specifici (i terminali seriali, se
 non addirittura le telescriventi). Oggi questa interfaccia viene in genere
 emulata o tramite programmi o con le cosiddette console virtuali associate a
 monitor e tastiera, ma esiste sempre la possibilità di associarla direttamente
-ad alcuni dispositivi, come eventuali linee seriali.\footnote{ed in certi
-  casi, come buona parte dei dispositivi embedded su cui gira Linux (come
-  router, access point, ecc.) questa resta anche l'unica opzione per una
-  \textit{console} di sistema.}
+ad alcuni dispositivi, come eventuali linee seriali, ed in certi casi, come
+buona parte dei dispositivi embedded su cui gira Linux (come router, access
+point, ecc.) questa resta anche l'unica opzione per una \textit{console} di
+sistema.
 
 
 \subsection{Il \textit{job control}}
@@ -56,50 +56,50 @@ ad alcuni dispositivi, come eventuali linee seriali.\footnote{ed in certi
 Viene comunemente chiamato \textit{job control} quell'insieme di funzionalità
 il cui scopo è quello di permettere ad un utente di poter sfruttare le
 capacità multitasking di un sistema Unix per eseguire in contemporanea più
-processi, pur potendo accedere, di solito, ad un solo terminale,\footnote{con
-  le interfacce grafiche di \textit{X Window} e con i terminali virtuali via
-  rete tutto questo non è più vero, dato che si può accedere a molti terminali
-  in contemporanea da una singola postazione di lavoro, ma il sistema è nato
-  prima dell'esistenza di tutto ciò.} avendo cioè un solo punto in cui si può
-avere accesso all'input ed all'output degli stessi.
+processi, pur potendo accedere, di solito, ad un solo terminale, avendo cioè
+un solo punto in cui si può avere accesso all'input ed all'output degli
+stessi. Con le interfacce grafiche di \textit{X Window} e con i terminali
+virtuali via rete oggi tutto questo non è più vero, dato che si può accedere a
+molti terminali in contemporanea da una singola postazione di lavoro, ma il
+sistema è nato prima dell'esistenza di tutto ciò.
 
 Il \textit{job control} è una caratteristica opzionale, introdotta in BSD
-negli anni '80, e successivamente standardizzata da POSIX.1; la sua
+negli anni '80, e successivamente standardizzata da POSIX.1. La sua
 disponibilità nel sistema è verificabile attraverso il controllo della macro
 \macro{\_POSIX\_JOB\_CONTROL}. In generale il \textit{job control} richiede il
 supporto sia da parte della shell (quasi tutte ormai lo hanno), che da parte
-del kernel; in particolare il kernel deve assicurare sia la presenza di un
+del kernel. In particolare il kernel deve assicurare sia la presenza di un
 driver per i terminali abilitato al \textit{job control} che quella dei
 relativi segnali illustrati in sez.~\ref{sec:sig_job_control}. 
 
 In un sistema che supporta il \textit{job control}, una volta completato il
 login, l'utente avrà a disposizione una shell dalla quale eseguire i comandi e
-potrà iniziare quella che viene chiamata una \textsl{sessione}, che riunisce
-(vedi sez.~\ref{sec:sess_proc_group}) tutti i processi eseguiti all'interno
-dello stesso login (esamineremo tutto il processo in dettaglio in
+potrà iniziare quella che viene chiamata una \textsl{sessione di lavoro}, che
+riunisce (vedi sez.~\ref{sec:sess_proc_group}) tutti i processi eseguiti
+all'interno dello stesso login (esamineremo tutto il processo in dettaglio in
 sez.~\ref{sec:sess_login}).
 
 Siccome la shell è collegata ad un solo terminale, che viene usualmente
 chiamato \textsl{terminale di controllo}, (vedi sez.~\ref{sec:sess_ctrl_term})
-un solo comando alla volta (quello che viene detto in \textit{foreground} o in
-\textsl{primo piano}), potrà scrivere e leggere dal terminale. La shell però
+un solo comando alla voltaquello che viene detto in \textit{foreground} o in
+\textsl{primo piano}, potrà scrivere e leggere dal terminale. La shell però
 può eseguire, aggiungendo una ``\cmd{\&}'' alla fine del comando, più
-programmi in contemporanea, mandandoli in \textit{background} (o \textsl{sullo
-  sfondo}), nel qual caso essi saranno eseguiti senza essere collegati al
-terminale.
+programmi in contemporanea, mandandoli come si dice, ``in
+\textit{background}'' (letteralmente ``\textsl{sullo sfondo}''), nel qual caso
+essi saranno eseguiti senza essere collegati al terminale.
 
-Si noti come si sia parlato di comandi e non di programmi o processi; fra le
+Si noti come si sia parlato di comandi e non di programmi o processi. Fra le
 funzionalità della shell infatti c'è anche quella di consentire di concatenare
-più programmi in una sola riga di comando con le pipe, ed in tal caso verranno
-eseguiti più programmi. Inoltre, anche quando si invoca un singolo programma,
-questo potrà sempre lanciare eventuali sotto-processi per eseguire dei compiti
-specifici.
-
-Per questo l'esecuzione di un comando può originare più di un processo; quindi
-nella gestione del \textit{job control} non si può far riferimento ai singoli
-processi.  Per questo il kernel prevede la possibilità di raggruppare più
-processi in un cosiddetto \itindex{process~group} \textit{process group}
-(detto anche \textsl{raggruppamento di processi}, vedi
+più comandi in una sola riga con il \textit{pipelining}, ed in tal caso
+verranno eseguiti più programmi. Inoltre, anche quando si invoca un singolo
+programma, questo potrà sempre lanciare eventuali sotto-processi per eseguire
+dei compiti specifici.
+
+Per questo l'esecuzione di una riga di comando può originare più di un
+processo, quindi nella gestione del \textit{job control} non si può far
+riferimento ai singoli processi.  Per questo il kernel prevede la possibilità
+di raggruppare più processi in un cosiddetto \itindex{process~group}
+\textit{process group} (detto anche \textsl{raggruppamento di processi}, vedi
 sez.~\ref{sec:sess_proc_group}). Deve essere cura della shell far sì che tutti
 i processi che originano da una stessa riga di comando appartengano allo
 stesso raggruppamento di processi, in modo che le varie funzioni di controllo,
@@ -118,19 +118,19 @@ Un comportamento analogo si ha anche per i segnali generati dai comandi di
 tastiera inviati dal terminale, che vengono inviati a tutti i processi del
 raggruppamento in \textit{foreground}. In particolare \cmd{C-z} interrompe
 l'esecuzione del comando, che può poi essere mandato in \textit{background}
-con il comando \cmd{bg}.\footnote{si tenga presente che \cmd{bg} e \cmd{fg}
-  sono parole chiave che indicano comandi interni alla shell, e nel caso non
-  comportano l'esecuzione di un programma esterno ma operazioni di gestione
-  compiute direttamente dalla shell stessa.} Il comando \cmd{fg} consente
-invece di mettere in \textit{foreground} un comando precedentemente lanciato
-in \textit{background}.
+con il comando \cmd{bg}. Il comando \cmd{fg} consente invece di mettere in
+\textit{foreground} un comando precedentemente lanciato in
+\textit{background}. Si tenga presente che \cmd{bg} e \cmd{fg} sono comandi
+interni alla shell, che non comportano l'esecuzione di un programma esterno,
+ma operazioni di gestione compiute direttamente dalla shell stessa.
 
-Di norma la shell si cura anche di notificare all'utente (di solito prima
-della stampa a video del prompt) lo stato dei vari processi; essa infatti sarà
-in grado, grazie all'uso di \func{waitpid}, di rilevare sia i processi che
-sono terminati, sia i raggruppamenti che sono bloccati (in questo caso usando
-l'opzione \const{WUNTRACED}, secondo quanto illustrato in
-sez.~\ref{sec:proc_wait}).
+Di norma la shell si cura anche di notificare all'utente, di solito prima
+della stampa a video del prompt, lo stato dei vari processi. Essa infatti sarà
+in grado, grazie all'uso della funzione di sistema \func{waitpid} (vedi
+sez.~\ref{sec:proc_wait}), di rilevare sia i processi che sono terminati, sia
+i raggruppamenti che sono bloccati, in quest'ultimo caso si dovrà usare la
+specifica opzione \const{WUNTRACED}, secondo quanto già illustrato in
+sez.~\ref{sec:proc_wait}.
 
 
 \subsection{I \textit{process group} e le \textsl{sessioni}}
@@ -146,114 +146,147 @@ processo:\footnote{in Linux questi identificatori sono mantenuti nei campi
   \var{pgrp} e \var{session} della struttura \kstruct{task\_struct} definita
   in \file{include/linux/sched.h}.}  l'identificatore del \textit{process
   group} e l'identificatore della \textsl{sessione}, che vengono indicati
-rispettivamente con le sigle \acr{pgid} e \acr{sid}, e sono mantenuti in
+rispettivamente con le sigle \ids{PGID} e \ids{SID}, e sono mantenuti in
 variabili di tipo \type{pid\_t}. I valori di questi identificatori possono
 essere visualizzati dal comando \cmd{ps} usando l'opzione \cmd{-j}.
 
 Un \textit{process group} è pertanto definito da tutti i processi che hanno lo
-stesso \acr{pgid}; è possibile leggere il valore di questo identificatore con
-le funzioni \funcd{getpgid} e \funcd{getpgrp},\footnote{\func{getpgrp} è
-  definita nello standard POSIX.1, mentre \func{getpgid} è richiesta da SVr4.}
-i cui prototipi sono:
-\begin{functions}
-  \headdecl{unistd.h}
+stesso \ids{PGID}; è possibile leggere il valore di questo identificatore con
+le funzioni di sistema \funcd{getpgid} e \funcd{getpgrp}, i cui prototipi
+sono:
 
-  \funcdecl{pid\_t getpgid(pid\_t pid)} 
-  Legge il \acr{pgid} del processo \param{pid}.
+\begin{funcproto}{
+\fhead{unistd.h}
+\fdecl{pid\_t getpgid(pid\_t pid)} 
+\fdesc{Legge il \ids{PGID} di un processo.} 
+\fdecl{pid\_t getpgrp(void)}
+\fdesc{Legge il \ids{PGID} del processo corrente.} 
+}
 
-  \funcdecl{pid\_t getpgrp(void)}
-  Legge il \acr{pgid} del processo corrente.
-  
-  \bodydesc{Le funzioni restituiscono il \acr{pgid} del processo,
-    \func{getpgrp} ha sempre successo, mentre \func{getpgid} restituisce -1
-    ponendo \var{errno} a \errval{ESRCH} se il processo selezionato non
-    esiste.}
-\end{functions}
+{Le funzioni ritornano il \ids{PGID} richiesto in caso di successo,
+  \func{getpgrp} ha sempre successo mentre \func{getpgid} restituisce $-1$ per
+  un errore, nel qual caso \var{errno} potrà assumere solo il valore
+  \errval{ESRCH} se il processo indicato non esiste.
+}
+\end{funcproto}
+
+Le due funzioni sono definite nello standard POSIX.1-2001, ma la prima deriva
+da SVr4 e la seconda da BSD4.2 dove però è previsto possa prendere un
+argomento per indicare il \ids{PID} di un altro processo. Si può riottenere
+questo comportamento se di definisce la macro \macro{\_BSD\_SOURCE} e non sono
+definite le altre macro che richiedono la conformità a POSIX, X/Open o SystemV
+(vedi sez.~\ref{sec:intro_standard}).
 
 La funzione \func{getpgid} permette di specificare il \ids{PID} del processo
-di cui si vuole sapere il \acr{pgid}; un valore nullo per \param{pid}
-restituisce il \acr{pgid} del processo corrente; \func{getpgrp} è di norma
-equivalente a \code{getpgid(0)}.
-
-In maniera analoga l'identificatore della sessione può essere letto dalla
-funzione \funcd{getsid}, che però nelle \acr{glibc}\footnote{la system call è
-  stata introdotta in Linux a partire dalla versione 1.3.44, il supporto nelle
-  librerie del C è iniziato dalla versione 5.2.19. La funzione non è prevista
-  da POSIX.1, che parla solo di processi leader di sessione, e non di
-  identificatori di sessione.} è accessibile solo definendo
-\macro{\_XOPEN\_SOURCE} e \macro{\_XOPEN\_SOURCE\_EXTENDED}; il suo prototipo
-è:
-\begin{prototype}{unistd.h}{pid\_t getsid(pid\_t pid)}
-  Legge l'identificatore di sessione del processo \param{pid}.
-  
-  \bodydesc{La funzione restituisce l'identificatore (un numero positivo) in
-  caso di successo, e -1 in caso di errore, nel qual caso \var{errno} assumerà
-  i valori:
-    \begin{errlist}
-    \item[\errcode{ESRCH}] il processo selezionato non esiste.
-    \item[\errcode{EPERM}] in alcune implementazioni viene restituito quando il
-      processo selezionato non fa parte della stessa sessione del processo
-      corrente.
-    \end{errlist}
-  }
-\end{prototype}
+di cui si vuole sapere il \ids{PGID}. Un valore nullo per \param{pid}
+restituisce il \ids{PGID} del processo corrente, che è il comportamento
+ordinario di \func{getpgrp}, che di norma equivalente a \code{getpgid(0)}.
+
+In maniera analoga l'identificatore della sessione di un processo (il
+\ids{SID}) può essere letto dalla funzione di sistema \funcd{getsid}, il cui
+prototipo è:
+
+\begin{funcproto}{
+\fhead{unistd.h}
+\fdecl{pid\_t getsid(pid\_t pid)}
+\fdesc{Legge il \ids{SID} di un processo.} 
+}
 
-Entrambi gli identificatori vengono inizializzati alla creazione di ciascun
-processo con lo stesso valore che hanno nel processo padre, per cui un
-processo appena creato appartiene sempre allo stesso raggruppamento e alla
-stessa sessione del padre. Vedremo poi come sia possibile creare più
-\textit{process group} all'interno della stessa sessione, e spostare i
-processi dall'uno all'altro, ma sempre all'interno di una stessa sessione.
+{La funzione ritorna l'identificatore (un numero positivo) in caso di successo
+  e $-1$ per un errore, nel qual caso \var{errno} assumerà uno dei valori:
+  \begin{errlist}
+    \item[\errcode{ESRCH}] il processo selezionato non esiste.
+    \item[\errcode{EPERM}] il processo selezionato non fa parte della stessa
+      sessione del processo corrente (solo in alcune implementazioni).
+  \end{errlist}
+}
+\end{funcproto}
+
+La funzione è stata introdotta in Linux a partire dal kernel 1.3.44, il
+supporto nelle librerie del C è iniziato dalla versione 5.2.19. La funzione
+non era prevista originariamente da POSIX.1, che parla solo di processi leader
+di sessione, e non di identificatori di sessione, ma è prevista da SVr4 e fa
+parte di POSIX.1-2001.  Per poterla utilizzare occorre definire la macro
+\macro{\_XOPEN\_SOURCE} ad un valore maggiore o uguale di 500. Su Linux
+l'errore \errval{EPERM} non viene mai restituito.
+
+Entrambi gli identificatori, \ids{SID} e \ids{PGID}, vengono inizializzati
+nella creazione di ciascun processo con lo stesso valore che hanno nel
+processo padre, per cui un processo appena creato appartiene sempre allo
+stesso raggruppamento e alla stessa sessione del padre. Vedremo a breve come
+sia possibile creare più \textit{process group} all'interno della stessa
+sessione, e spostare i processi dall'uno all'altro, ma sempre all'interno di
+una stessa sessione.
 
 Ciascun raggruppamento di processi ha sempre un processo principale, il
-cosiddetto \itindex{process~group~leader} \textit{process group leader}, che è
-identificato dall'avere un \acr{pgid} uguale al suo \ids{PID}, in genere
-questo è il primo processo del raggruppamento, che si incarica di lanciare
-tutti gli altri. Un nuovo raggruppamento si crea con la funzione
-\funcd{setpgrp},\footnote{questa è la definizione di POSIX.1, BSD definisce
-  una funzione con lo stesso nome, che però è identica a \func{setpgid}; nelle
-  \acr{glibc} viene sempre usata sempre questa definizione, a meno di non
-  richiedere esplicitamente la compatibilità all'indietro con BSD, definendo
-  la macro \macro{\_BSD\_SOURCE}.} il cui prototipo è:
-\begin{prototype}{unistd.h}{int setpgrp(void)}
-  Modifica il \acr{pgid} al valore del \ids{PID} del processo corrente.
-  
-  \bodydesc{La funzione restituisce il valore del nuovo \textit{process
-      group}.}
-\end{prototype}
+cosiddetto \itindex{process~group~leader} \textit{process group leader} o più
+brevemente \textit{group leader}, che è identificato dall'avere un \ids{PGID}
+uguale al suo \ids{PID}. In genere questo è il primo processo del
+raggruppamento, che si incarica di lanciare tutti gli altri. Un nuovo
+raggruppamento si crea con la funzione di sistema \funcd{setpgrp}, il cui
+prototipo è:
 
-La funzione, assegnando al \acr{pgid} il valore del \ids{PID} processo
-corrente, rende questo \itindex{process~group~leader} \textit{group leader} di
-un nuovo raggruppamento, tutti i successivi processi da esso creati
-apparterranno (a meno di non cambiare di nuovo il \acr{pgid}) al nuovo
-raggruppamento. È possibile invece spostare un processo da un raggruppamento
-ad un altro con la funzione \funcd{setpgid}, il cui prototipo è:
-\begin{prototype}{unistd.h}{int setpgid(pid\_t pid, pid\_t pgid)}
-  Assegna al \acr{pgid} del processo \param{pid} il valore \param{pgid}.
-  
-  \bodydesc{La funzione ritorna il valore del nuovo \textit{process group}, e
-  -1 in caso di errore, nel qual caso \var{errno} assumerà i valori:
-    \begin{errlist}
+\begin{funcproto}{
+\fhead{unistd.h}
+\fdecl{int setpgrp(void)}
+\fdesc{Rende un processo \textit{group leader} di un nuovo gruppo.} 
+}
+
+{La funzione ritorna il valore del nuovo \textit{process group} e non sono
+  previsti errori.}
+\end{funcproto}
+
+La funzione assegna al \ids{PGID} il valore del \ids{PID} del processo
+corrente, rendendolo in tal modo \itindex{process~group~leader} \textit{group
+  leader} di un nuovo raggruppamento. Tutti i successivi processi da esso
+creati apparterranno (a meno di non cambiare di nuovo il \ids{PGID}) al nuovo
+raggruppamento. 
+
+La versione illustrata è quella usata nella definizione di POSIX.1, in BSD
+viene usata una funzione con questo nome, che però è identica a
+\func{setpgid}, che vedremo a breve, negli argomenti e negli effetti. Nelle
+\acr{glibc} viene sempre usata sempre questa definizione, a meno di non
+richiedere esplicitamente la compatibilità all'indietro con BSD, definendo la
+macro \macro{\_BSD\_SOURCE} ed evitando di definire le macro che richiedono
+gli altri standard, come per \func{getpgrp}.
+
+È inoltre possibile spostare un processo da un raggruppamento di processi ad
+un altro cambiandone il \ids{PGID} con la funzione di sistema \funcd{setpgid},
+il cui prototipo è:
+
+\begin{funcproto}{
+\fhead{unistd.h}
+\fdecl{int setpgid(pid\_t pid, pid\_t pgid)}
+\fdesc{Modifica il \ids{PGID} di un processo.} 
+}
+
+{La funzione ritorna il valore del nuovo \textit{process group}  in caso di
+  successo e $-1$ per un errore, nel qual caso \var{errno} assumerà uno dei
+  valori:
+  \begin{errlist}
     \item[\errcode{ESRCH}] il processo selezionato non esiste.
     \item[\errcode{EPERM}] il cambiamento non è consentito.
-    \item[\errcode{EACCES}] il processo ha già eseguito una \func{exec}.
+    \item[\errcode{EACCES}] il processo di cui si vuole cambiare il \ids{PGID}
+      ha già eseguito una \func{exec}.
     \item[\errcode{EINVAL}] il valore di \param{pgid} è negativo.
-    \end{errlist}
- }
-\end{prototype}
-
-La funzione permette di cambiare il \acr{pgid} del processo \param{pid}, ma il
-cambiamento può essere effettuato solo se \param{pgid} indica un
-\textit{process group} che è nella stessa sessione del processo chiamante.
-Inoltre la funzione può essere usata soltanto sul processo corrente o su uno
-dei suoi figli, ed in quest'ultimo caso ha successo soltanto se questo non ha
-ancora eseguito una \func{exec}.\footnote{questa caratteristica è implementata
-  dal kernel che mantiene allo scopo un altro campo, \var{did\_exec}, in
-  \struct{task\_struct}.}  Specificando un valore nullo per \param{pid} si
-indica il processo corrente, mentre specificando un valore nullo per
-\param{pgid} si imposta il \textit{process group} al valore del \ids{PID} del
-processo selezionato; pertanto \func{setpgrp} è equivalente a \code{setpgid(0,
-  0)}.
+  \end{errlist}
+}
+\end{funcproto}
+
+
+La funzione permette di cambiare il \ids{PGID} del processo indicato
+dall'argomento \param{pid}, ma il cambiamento può essere effettuato solo se
+l'argomento \param{pgid} indica un \textit{process group} che è nella stessa
+sessione del processo chiamante.  Inoltre la funzione può essere usata
+soltanto sul processo corrente o su uno dei suoi figli, ed in quest'ultimo
+caso ha successo soltanto se questo non ha ancora eseguito una
+\func{exec}.\footnote{questa caratteristica è implementata dal kernel che
+  mantiene allo scopo un altro campo, \var{did\_exec}, nella struttura
+  \kstruct{task\_struct}.}  Specificando un valore nullo per \param{pid} si
+indica il processo corrente, mentre specificando un valore nullo
+per \param{pgid} si imposta il \textit{process group} al valore del \ids{PID}
+del processo selezionato, questo significa che \func{setpgrp} è equivalente a
+\code{setpgid(0, 0)}.
 
 Di norma questa funzione viene usata dalla shell quando si usano delle
 pipeline, per mettere nello stesso \textit{process group} tutti i programmi
@@ -267,38 +300,45 @@ occorre eseguirle comunque entrambe per evitare di esporsi ad una
 
 Si noti come nessuna delle funzioni esaminate finora permetta di spostare un
 processo da una sessione ad un altra; infatti l'unico modo di far cambiare
-sessione ad un processo è quello di crearne una nuova con l'uso di
-\funcd{setsid}; il suo prototipo è:
-\begin{prototype}{unistd.h}{pid\_t setsid(void)}
-  Crea una nuova sessione sul processo corrente impostandone \acr{sid} e
-  \acr{pgid}.
-  
-  \bodydesc{La funzione ritorna il valore del nuovo \acr{sid}, e -1 in caso di
-    errore, il solo errore possibile è \errval{EPERM}, che si ha quando il
-    \acr{pgid} e \ids{PID} del processo coincidono.}
-\end{prototype}
+sessione ad un processo è quello di crearne una nuova con l'uso della funzione
+di sistema \funcd{setsid}, il cui prototipo è:
+
+\begin{funcproto}{
+\fhead{unistd.h}
+\fdecl{pid\_t setsid(void)}
+\fdesc{Crea una nuova sessione sul processo corrente.} 
+}
+
+{La funzione ritorna il valore del nuovo \ids{SID} in caso di successo e $-1$
+  per un errore, nel qual caso \var{errno} assumerà uno dei valori:
+  \begin{errlist}
+  \item[\errcode{EPERM}] il \ids{PGID} e \ids{PID} del processo coincidono.
+  \end{errlist}
+}
+\end{funcproto}
+
 
-La funzione imposta il \acr{pgid} ed il \acr{sid} del processo corrente al
+La funzione imposta il \ids{PGID} ed il \ids{SID} del processo corrente al
 valore del suo \ids{PID}, creando così una nuova sessione ed un nuovo
 \textit{process group} di cui esso diventa leader (come per i \textit{process
-  group} un processo si dice leader di sessione\footnote{in Linux la proprietà
-  è mantenuta in maniera indipendente con un apposito campo \var{leader} in
-  \struct{task\_struct}.} se il suo \acr{sid} è uguale al suo \ids{PID}) ed
-unico componente.  Inoltre la funzione distacca il processo da ogni terminale
-di controllo (torneremo sull'argomento in sez.~\ref{sec:sess_ctrl_term}) cui
-fosse in precedenza associato.
+  group} un processo si dice \textsl{leader di sessione} se il suo \ids{SID} è
+uguale al suo \ids{PID}) ed unico componente.\footnote{in Linux la proprietà è
+  mantenuta in maniera indipendente con un apposito campo \var{leader} in
+  \kstruct{task\_struct}.} Inoltre la funzione distacca il processo da ogni
+terminale di controllo (torneremo sull'argomento in
+sez.~\ref{sec:sess_ctrl_term}) cui fosse in precedenza associato.
 
 La funzione ha successo soltanto se il processo non è già
 \itindex{process~group~leader} leader di un \textit{process group}, per cui
 per usarla di norma si esegue una \func{fork} e si esce, per poi chiamare
 \func{setsid} nel processo figlio, in modo che, avendo questo lo stesso
-\acr{pgid} del padre ma un \ids{PID} diverso, non ci siano possibilità di
+\ids{PGID} del padre ma un \ids{PID} diverso, non ci siano possibilità di
 errore.\footnote{potrebbe sorgere il dubbio che, per il riutilizzo dei valori
   dei \ids{PID} fatto nella creazione dei nuovi processi (vedi
   sez.~\ref{sec:proc_pid}), il figlio venga ad assumere un valore
   corrispondente ad un \textit{process group} esistente; questo viene evitato
   dal kernel che considera come disponibili per un nuovo \ids{PID} solo valori
-  che non corrispondono ad altri \ids{PID}, \acr{pgid} o \acr{sid} in uso nel
+  che non corrispondono ad altri \ids{PID}, \ids{PGID} o \ids{SID} in uso nel
   sistema.} Questa funzione viene usata di solito nel processo di login (per i
 dettagli vedi sez.~\ref{sec:sess_login}) per raggruppare in una sessione tutti
 i comandi eseguiti da un utente dalla sua shell.
@@ -324,7 +364,7 @@ mantenendo fra gli attributi di ciascun processo anche qual'è il suo terminale
 di controllo.\footnote{lo standard POSIX.1 non specifica nulla riguardo
   l'implementazione; in Linux anch'esso viene mantenuto nella solita struttura
   \struct{task\_struct}, nel campo \var{tty}.}  In generale ogni processo
-eredita dal padre, insieme al \acr{pgid} e al \acr{sid} anche il terminale di
+eredita dal padre, insieme al \ids{PGID} e al \ids{SID} anche il terminale di
 controllo (vedi sez.~\ref{sec:proc_fork}). In questo modo tutti processi
 originati dallo stesso leader di sessione mantengono lo stesso terminale di
 controllo.
@@ -395,7 +435,7 @@ ad un terminale con la funzione \funcd{tcgetpgrp}, il cui prototipo è:
   
   \funcdecl{pid\_t tcgetpgrp(int fd)} Legge il \textit{process group} di
   \textit{foreground} del terminale associato al file descriptor \param{fd}.
-  \bodydesc{La funzione restituisce in caso di successo il \acr{pgid} del
+  \bodydesc{La funzione restituisce in caso di successo il \ids{PGID} del
     gruppo di \textit{foreground}, e -1 in caso di errore, nel qual caso
     \var{errno} assumerà i valori:
     \begin{errlist}
@@ -660,7 +700,7 @@ occorrerà predisporlo in modo che esso compia le seguenti azioni:
 \item Eseguire una \func{fork} e terminare immediatamente il processo padre
   proseguendo l'esecuzione nel figlio.  In questo modo si ha la certezza che
   il figlio non è un \itindex{process~group~leader} \textit{process group
-    leader}, (avrà il \acr{pgid} del padre, ma un \ids{PID} diverso) e si può
+    leader}, (avrà il \ids{PGID} del padre, ma un \ids{PID} diverso) e si può
   chiamare \func{setsid} con successo. Inoltre la shell considererà terminato
   il comando all'uscita del padre.
 \item Eseguire \func{setsid} per creare una nuova sessione ed un nuovo