%% License".
%%
-\chapter{Interfaccia utente: terminali e sessioni di lavoro}
+\chapter{Terminali e sessioni di lavoro}
\label{cha:session}
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}}
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 volta, quello 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,
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}}
\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
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.
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.
\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}
\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
projects / gapil.git / commitdiff