%% session.tex
%%
-%% Copyright (C) 2000-2004 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2005 Simone Piccardi. Permission is granted to
%% copy, distribute and/or modify this document under the terms of the GNU Free
%% Documentation License, Version 1.1 or any later version published by the
%% Free Software Foundation; with the Invariant Sections being "Un preambolo",
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}),
-potrà scrivere e leggere dal terminale. La shell però può eseguire anche più
-comandi in contemporanea, mandandoli in \textit{background} (aggiungendo una
-\cmd{\&} alla fine del comando), nel qual caso essi saranno eseguiti senza
-essere collegati al terminale.
+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.
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
Per questo l'esecuzione di un comando può originare più di un processo; quindi
nella gestione del job control non si può far riferimento ai singoli processi.
Per questo il kernel prevede la possibilità di raggruppare più processi in un
-\textit{process group} (detto anche \textsl{raggruppamento di processi}, vedi
-sez.~\ref{sec:sess_proc_group}) e la shell farà sì che tutti i processi che
-originano da una riga di comando appartengano allo stesso raggruppamento, in
-modo che le varie funzioni di controllo, ed i segnali inviati dal terminale,
-possano fare riferimento ad esso.
+\itindex{process~group} \textit{process group} (detto anche
+\textsl{raggruppamento di processi}, vedi sez.~\ref{sec:sess_proc_group}) e la
+shell farà sì che tutti i processi che originano da una riga di comando
+appartengano allo stesso raggruppamento, in modo che le varie funzioni di
+controllo, ed i segnali inviati dal terminale, possano fare riferimento ad
+esso.
In generale allora all'interno di una sessione avremo un eventuale (può non
-esserci) \textit{process group} in \textit{foreground}, che riunisce i
-processi che possono accedere al terminale, e più \textit{process group} in
-\textit{background}, che non possono accedervi. Il job control prevede che
-quando un processo appartenente ad un raggruppamento in \textit{background}
-cerca di accedere al terminale, venga inviato un segnale a tutti i processi
-del raggruppamento, in modo da bloccarli (vedi sez.~\ref{sec:sess_ctrl_term}).
+esserci) \itindex{process~group} \textit{process group} in
+\textit{foreground}, che riunisce i processi che possono accedere al
+terminale, e più \textit{process group} in \textit{background}, che non
+possono accedervi. Il job control prevede che quando un processo appartenente
+ad un raggruppamento in \textit{background} cerca di accedere al terminale,
+venga inviato un segnale a tutti i processi del raggruppamento, in modo da
+bloccarli (vedi sez.~\ref{sec:sess_ctrl_term}).
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
\subsection{I \textit{process group} e le \textsl{sessioni}}
\label{sec:sess_proc_group}
+\itindbeg{process~group}
+
Come accennato in sez.~\ref{sec:sess_job_control_overview} nel job control i
-processi vengono raggruppati in \textit{process group} e \textit{sessioni};
+processi vengono raggruppati in \textit{process group} e \textsl{sessioni};
per far questo vengono utilizzati due ulteriori identificatori (oltre quelli
visti in sez.~\ref{sec:proc_pid}) che il kernel associa a ciascun
processo:\footnote{in Linux questi identificatori sono mantenuti nei campi
processi dall'uno all'altro, ma sempre all'interno di una stessa sessione.
Ciascun raggruppamento di processi ha sempre un processo principale, il
-cosiddetto \textit{process group leader}, che è identificato dall'avere un
-\acr{pgid} uguale al suo \acr{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 è:
+cosiddetto \itindex{process~group~leader}\textit{process group leader}, che è
+identificato dall'avere un \acr{pgid} uguale al suo \acr{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 \acr{pid} del processo corrente.
\end{prototype}
La funzione, assegnando al \acr{pgid} il valore del \acr{pid} processo
-corrente, rende questo \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 è:
+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}.
0)}.
Di norma questa funzione viene usata dalla shell quando si usano delle
-pipeline, per mettere nello stesso process group tutti i programmi lanciati su
-ogni linea di comando; essa viene chiamata dopo una \func{fork} sia dal
-processo padre, per impostare il valore nel figlio, che da quest'ultimo, per
-sé stesso, in modo che il cambiamento di \textit{process group} sia immediato
-per entrambi; una delle due chiamate sarà ridondante, ma non potendo
-determinare quale dei due processi viene eseguito per primo, occorre eseguirle
-comunque entrambe per evitare di esporsi ad una race
-condition\index{\textit{race~condition}}.
+pipeline, per mettere nello stesso \textit{process group} tutti i programmi
+lanciati su ogni linea di comando; essa viene chiamata dopo una \func{fork}
+sia dal processo padre, per impostare il valore nel figlio, che da
+quest'ultimo, per sé stesso, in modo che il cambiamento di \textit{process
+ group} sia immediato per entrambi; una delle due chiamate sarà ridondante,
+ma non potendo determinare quale dei due processi viene eseguito per primo,
+occorre eseguirle comunque entrambe per evitare di esporsi ad una \textit{race
+ condition}\itindex{race~condition}.
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
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à 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 \acr{pid} diverso, non ci
-siano possibilità di errore.\footnote{potrebbe sorgere il dubbio che, per il
- riutilizzo dei valori dei \acr{pid} fatto nella creazione dei nuovi processi
- (vedi sez.~\ref{sec:proc_pid}), il figlio venga ad assumere un valore
- corrispondente ad un process group esistente; questo viene evitato dal
- kernel che considera come disponibili per un nuovo \acr{pid} solo valori che
- non corrispondono ad altri \acr{pid}, \acr{pgid} o \acr{sid} in uso nel
+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 \acr{pid} diverso, non ci siano possibilità di
+errore.\footnote{potrebbe sorgere il dubbio che, per il riutilizzo dei valori
+ dei \acr{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 \acr{pid} solo valori
+ che non corrispondono ad altri \acr{pid}, \acr{pgid} o \acr{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.
-
+\itindend{process~group}
\subsection{Il terminale di controllo e il controllo di sessione}
\label{sec:sess_ctrl_term}
A tale scopo lo standard POSIX.1 prevede che ad ogni sessione possa essere
associato un terminale di controllo; in Linux questo viene realizzato
mantenendo fra gli attributi di ciascun processo anche qual'è il suo terminale
-di controllo. \footnote{Lo standard POSIX.1 non specifica nulla riguardo
+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
\noindent la funzione può essere eseguita con successo solo da
un processo nella stessa sessione e con lo stesso terminale di controllo.
-Come accennato in sez.~\ref{sec:sess_job_control_overview}, tutti i processi (e
-relativi raggruppamenti) che non fanno parte del gruppo di \textit{foreground}
-sono detti in \textit{background}; se uno si essi cerca di accedere al
-terminale di controllo provocherà l'invio da parte del kernel di uno dei due
-segnali \const{SIGTTIN} o \const{SIGTTOU} (a seconda che l'accesso sia stato
-in lettura o scrittura) a tutto il suo \textit{process group}; dato che il
-comportamento di default di questi segnali (si riveda quanto esposto in
-sez.~\ref{sec:sig_job_control}) è di fermare il processo, di norma questo
-comporta che tutti i membri del gruppo verranno fermati, ma non si avranno
-condizioni di errore.\footnote{la shell in genere notifica comunque un
- avvertimento, avvertendo la presenza di processi bloccati grazie all'uso di
- \func{waitpid}.} Se però si bloccano o ignorano i due segnali citati, le
-funzioni di lettura e scrittura falliranno con un errore di \errcode{EIO}.
-
-Un processo può controllare qual'è il gruppo di \textit{foreground} associato
+Come accennato in sez.~\ref{sec:sess_job_control_overview}, tutti i processi
+(e relativi raggruppamenti) che non fanno parte del gruppo di
+\textit{foreground} sono detti in \textit{background}; se uno si essi cerca di
+accedere al terminale di controllo provocherà l'invio da parte del kernel di
+uno dei due segnali \const{SIGTTIN} o \const{SIGTTOU} (a seconda che l'accesso
+sia stato in lettura o scrittura) a tutto il suo \itindex{process~group}
+\textit{process group}; dato che il comportamento di default di questi segnali
+(si riveda quanto esposto in sez.~\ref{sec:sig_job_control}) è di fermare il
+processo, di norma questo comporta che tutti i membri del gruppo verranno
+fermati, ma non si avranno condizioni di errore.\footnote{la shell in genere
+ notifica comunque un avvertimento, avvertendo la presenza di processi
+ bloccati grazie all'uso di \func{waitpid}.} Se però si bloccano o ignorano i
+due segnali citati, le funzioni di lettura e scrittura falliranno con un
+errore di \errcode{EIO}.
+
+Un processo può controllare qual è il gruppo di \textit{foreground} associato
ad un terminale con la funzione \funcd{tcgetpgrp}, il cui prototipo è:
\begin{functions}
\headdecl{unistd.h} \headdecl{termios.h}
\const{SIGQUIT} e \const{SIGTERM}, trattati in sez.~\ref{sec:sig_job_control})
a tutti i processi del raggruppamento di \textit{foreground}; in questo modo
la shell può gestire il blocco e l'interruzione dei vari comandi.
-
+
+
Per completare la trattazione delle caratteristiche del job control legate al
terminale di controllo, occorre prendere in considerazione i vari casi legati
alla terminazione anomala dei processi, che sono di norma gestite attraverso
il segnale \const{SIGHUP}. Il nome del segnale deriva da \textit{hungup},
termine che viene usato per indicare la condizione in cui il terminale diventa
-inutilizzabile, (letteralmente sarebbe \textsl{impiccagione}).
+inutilizzabile, (letteralmente sarebbe \textsl{impiccagione}).
Quando si verifica questa condizione, ad esempio se si interrompe la linea, o
va giù la rete o più semplicemente si chiude forzatamente la finestra di
controllo dello stesso.
Questa è la situazione in cui si ha quello che viene chiamato un
-\textit{orphaned process group}. Lo standard POSIX.1 lo definisce come un
-\textit{process group} i cui processi hanno come padri esclusivamente o altri
-processi nel raggruppamento, o processi fuori della sessione. Lo standard
-prevede inoltre che se la terminazione di un processo fa sì che un
-raggruppamento di processi diventi orfano e se i suoi membri sono bloccati, ad
-essi vengano inviati in sequenza i segnali di \const{SIGHUP} e
-\const{SIGCONT}.
+\itindex{process~group~orphaned} \textit{orphaned process group}. Lo standard
+POSIX.1 lo definisce come un \itindex{process~group} \textit{process group} i
+cui processi hanno come padri esclusivamente o altri processi nel
+raggruppamento, o processi fuori della sessione. Lo standard prevede inoltre
+che se la terminazione di un processo fa sì che un raggruppamento di processi
+diventi orfano e se i suoi membri sono bloccati, ad essi vengano inviati in
+sequenza i segnali di \const{SIGHUP} e \const{SIGCONT}.
La definizione può sembrare complicata, e a prima vista non è chiaro cosa
tutto ciò abbia a che fare con il problema della terminazione del processo di
controllo. Consideriamo allora cosa avviene di norma nel \textit{job
control}: una sessione viene creata con \func{setsid} che crea anche un
-nuovo process group: per definizione quest'ultimo è sempre \textsl{orfano},
-dato che il padre del leader di sessione è fuori dalla stessa e il nuovo
-process group contiene solo il leader di sessione. Questo è un caso limite, e
-non viene emesso nessun segnale perché quanto previsto dallo standard riguarda
-solo i raggruppamenti che diventano orfani in seguito alla terminazione di un
-processo.\footnote{l'emissione dei segnali infatti avviene solo nella fase di
- uscita del processo, come una delle operazioni legate all'esecuzione di
- \func{\_exit}, secondo quanto illustrato in sez.~\ref{sec:proc_termination}.}
+nuovo \itindex{process~group} \textit{process group}: per definizione
+quest'ultimo è sempre \textsl{orfano}, dato che il padre del leader di
+sessione è fuori dalla stessa e il nuovo \textit{process group}
+\itindex{process~group} contiene solo il leader di sessione. Questo è un caso
+limite, e non viene emesso nessun segnale perché quanto previsto dallo
+standard riguarda solo i raggruppamenti che diventano orfani in seguito alla
+terminazione di un processo.\footnote{l'emissione dei segnali infatti avviene
+ solo nella fase di uscita del processo, come una delle operazioni legate
+ all'esecuzione di \func{\_exit}, secondo quanto illustrato in
+ sez.~\ref{sec:proc_termination}.}
Il leader di sessione provvederà a creare nuovi raggruppamenti che a questo
punto non sono orfani in quanto esso resta padre per almeno uno dei processi
Quando viene lanciato da \cmd{init} il programma parte con i privilegi di
amministratore e con un ambiente vuoto; \cmd{getty} si cura di chiamare
-\func{setsid} per creare una nuova sessione ed un nuovo process group, e di
-aprire il terminale (che così diventa il terminale di controllo della
-sessione) in lettura sullo standard input ed in scrittura sullo standard
-output e sullo standard error; inoltre effettuerà, qualora servano, ulteriori
-settaggi.\footnote{ad esempio, come qualcuno si sarà accorto scrivendo un nome
- di login in maiuscolo, può effettuare la conversione automatica dell'input
- in minuscolo, ponendosi in una modalità speciale che non distingue fra i due
- tipi di caratteri (a beneficio di alcuni vecchi terminali che non
- supportavano le minuscole).} Alla fine il programma stamperà un messaggio di
-benvenuto per poi porsi in attesa dell'immissione del nome di un utente.
+\func{setsid} per creare una nuova sessione ed un nuovo
+\itindex{process~group} \textit{process group}, e di aprire il terminale (che
+così diventa il terminale di controllo della sessione) in lettura sullo
+standard input ed in scrittura sullo standard output e sullo standard error;
+inoltre effettuerà, qualora servano, ulteriori settaggi.\footnote{ad esempio,
+ come qualcuno si sarà accorto scrivendo un nome di login in maiuscolo, può
+ effettuare la conversione automatica dell'input in minuscolo, ponendosi in
+ una modalità speciale che non distingue fra i due tipi di caratteri (a
+ beneficio di alcuni vecchi terminali che non supportavano le minuscole).}
+Alla fine il programma stamperà un messaggio di benvenuto per poi porsi in
+attesa dell'immissione del nome di un utente.
Una volta che si sia immesso il nome di login \cmd{getty} esegue direttamente
il programma \cmd{login} con una \func{exevle}, passando come argomento la
volta criptato, ed è il risultato che viene confrontato con il valore che
viene mantenuto nel database degli utenti.} la richiesta viene ripetuta un
certo numero di volte dopo di che \cmd{login} esce ed \cmd{init} provvede a
-rilanciare un'altra istanza di \func{getty}.
+rilanciare un'altra istanza di \cmd{getty}.
Se invece la password corrisponde \cmd{login} esegue \func{chdir} per settare
la \textit{home directory} dell'utente, cambia i diritti di accesso al
verrà cambiata l'identità del proprietario del processo, infatti, come
spiegato in sez.~\ref{sec:proc_setuid}, avendo invocato tali funzioni con i
privilegi di amministratore, tutti gli user-ID ed i group-ID (reali, effettivi
-e salvati) saranno settati a quelli dell'utente.
+e salvati) saranno impostati a quelli dell'utente.
A questo punto \cmd{login} provvederà (fatte salve eventuali altre azioni
iniziali, come la stampa di messaggi di benvenuto o il controllo della posta)
Dato che il processo padre resta sempre \cmd{init} quest'ultimo potrà
provvedere, ricevendo un \const{SIGCHLD} all'uscita della shell quando la
sessione di lavoro è terminata, a rilanciare \cmd{getty} sul terminale per
-ripetere da capo tutto il procedimento.
+ripetere da capo tutto il procedimento.
\begin{enumerate}
\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 \textit{process group leader}, (avrà il \acr{pgid} del
- padre, ma un \acr{pid} diverso) e si può chiamare \func{setsid} con
- successo. Inoltre la shell considererà terminato il comando all'uscita del
- padre.
+ il figlio non è un \itindex{process~group~leader} \textit{process group
+ leader}, (avrà il \acr{pgid} del padre, ma un \acr{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
raggruppamento di cui il processo diventa automaticamente il leader, che
però non ha associato nessun terminale di controllo.
L'argomento \param{priority} permette di impostare sia la \textit{facility}
che la \textit{priority} del messaggio. In realtà viene prevalentemente usato
-per specificare solo quest'ultima in quanto la prima viene di norma
+per specificare solo quest'ultima in quanto la prima viene di norma
preimpostata con \func{openlog}. La priorità è indicata con un valore
numerico\footnote{le \acr{glibc}, seguendo POSIX.1-2001, prevedono otto
diverse priorità ordinate da 0 a 7, in ordine di importanza decrescente;
Le routine di gestione mantengono per ogni processo una maschera che determina
quale delle chiamate effettuate a \func{syslog} verrà effettivamente
registrata. La registrazione viene disabilitata per tutte quelle priorità che
-non rientrano nella maschera; questa viene settata usando la macro
+non rientrano nella maschera; questa viene impostata usando la macro
\macro{LOG\_MASK(p)} dove \code{p} è una delle costanti di
tab.~\ref{tab:sess_syslog_priority}. É inoltre disponibile anche la macro
\macro{LOG\_UPTO(p)} che permette di specificare automaticamente tutte le
kernel.
\begin{figure}[htb]
- \centering \includegraphics[width=13cm]{img/term_struct}
+ \centering \includegraphics[width=14.5cm]{img/term_struct}
\caption{Struttura interna generica di un driver per un terminale.}
\label{fig:term_struct}
\end{figure}
automaticamente un avviso (un carattere di BELL, che provoca un beep)
sull'output quando si eccedono le dimensioni della coda. Se è abilitato il
modo canonico i caratteri in ingresso restano nella coda fintanto che non
-viene ricevuto un a capo; un'altra parametro del sistema, \const{MAX\_CANON},
+viene ricevuto un a capo; un'altro parametro del sistema, \const{MAX\_CANON},
specifica la dimensione massima di una riga in modo canonico.
La coda di uscita è analoga a quella di ingresso e contiene i caratteri
\textit{pathname} del terminale.}
\end{prototype}
-La funzione scrive il \index{\textit{pathname}}\textit{pathname} del terminale
-di controllo del processo chiamante nella stringa posta all'indirizzo
-specificato dall'argomento \param{s}. La memoria per contenere la stringa
-deve essere stata allocata in precedenza ed essere lunga almeno
+La funzione scrive il \itindex{pathname}\textit{pathname} del terminale di
+controllo del processo chiamante nella stringa posta all'indirizzo specificato
+dall'argomento \param{s}. La memoria per contenere la stringa deve essere
+stata allocata in precedenza ed essere lunga almeno
\const{L\_ctermid}\footnote{\const{L\_ctermid} è una delle varie costanti del
sistema, non trattata esplicitamente in sez.~\ref{sec:sys_characteristics}
che indica la dimensione che deve avere una stringa per poter contenere il
Se si passa come argomento \val{NULL} la funzione restituisce il puntatore ad
una stringa statica che può essere sovrascritta da chiamate successive. Si
-tenga presente che il \index{\textit{pathname}}\textit{pathname} restituito
+tenga presente che il \itindex{pathname}\textit{pathname} restituito
potrebbe non identificare univocamente il terminale (ad esempio potrebbe
essere \file{/dev/tty}), inoltre non è detto che il processo possa
effettivamente aprire il terminale.
parità, se non impostato un carattere con errori di
parità viene letto come uno \texttt{0x00}. Se un
carattere ha il valore \texttt{0xFF} e \const{ISTRIP}
- non è settato, per evitare ambiguità esso viene sempre
+ non è impostato, per evitare ambiguità esso viene sempre
riportato come \texttt{0xFF 0xFF}.\\
\const{ISTRIP} & Se impostato i caratteri in input sono tagliati a sette
bit mettendo a zero il bit più significativo, altrimenti
gruppo in foreground anche l'invio di \const{SIGINT} ai
processi di quest'ultimo. Se invece \const{BRKINT} non è
impostato un BREAK viene letto come un carattere
- NUL, a meno che non sia settato \const{PARMRK}
+ NUL, a meno che non sia impostato \const{PARMRK}
nel qual caso viene letto come la sequenza di caratteri
\texttt{0xFF 0x00 0x00}.\\
\const{IGNCR} & Se impostato il carattere di ritorno carrello
carattere START. \\
\const{IMAXBEL}& Se impostato fa suonare il cicalino se si riempie la cosa
di ingresso; in Linux non è implementato e il kernel si
- comporta cose se fosse sempre settato (è una estensione
+ comporta cose se fosse sempre impostato (è una estensione
BSD). \\
\hline
\end{tabular}
\const{TOSTOP} & Se abilitato, con il supporto per il job control presente,
genera il segnale \const{SIGTTOU} per un processo in
background che cerca di scrivere sul terminale.\\
- \const{XCASE} & Se settato il terminale funziona solo con le
+ \const{XCASE} & Se impostato il terminale funziona solo con le
maiuscole. L'input è convertito in minuscole tranne per i
caratteri preceduti da una \verb|\|. In output le
maiuscole sono precedute da una \verb|\| e le minuscole
convertite in maiuscole.\\
- \const{DEFECHO}& Se impostate effettua l'eco solo se c'è un processo in
+ \const{DEFECHO}& Se impostato effettua l'eco solo se c'è un processo in
lettura.\\
\const{FLUSHO} & Effettua la cancellazione della coda di uscita. Viene
attivato dal carattere DISCARD. Non è supportato in
La maggior parte di questi caratteri (tutti tranne \const{VTIME} e
\const{VMIN}) hanno effetto solo quando il terminale viene utilizzato in modo
canonico; per alcuni devono essere soddisfatte ulteriori richieste, ad esempio
-\const{VINTR}, \const{VSUSP}, e \const{VQUIT} richiedono sia settato
-\const{ISIG}; \const{VSTART} e \const{VSTOP} richiedono sia settato
+\const{VINTR}, \const{VSUSP}, e \const{VQUIT} richiedono sia impostato
+\const{ISIG}; \const{VSTART} e \const{VSTOP} richiedono sia impostato
\const{IXON}; \const{VLNEXT}, \const{VWERASE}, \const{VREPRINT} richiedono sia
-settato \const{IEXTEN}. In ogni caso quando vengono attivati i caratteri
+impostato \const{IEXTEN}. In ogni caso quando vengono attivati i caratteri
vengono interpretati e non sono passati sulla coda di ingresso.
Per leggere ed scrivere tutte le varie impostazioni dei terminali viste finora
Anche in questo caso le due funzioni estraggono i valori della velocità della
linea da una struttura, il cui indirizzo è specificato dall'argomento
\param{termios\_p} che deve essere stata letta in precedenza con
-\func{tcgetaddr}.
+\func{tcgetattr}.
funzioni di scrittura, pertanto se usate da processi in background sul loro
terminale di controllo provocano l'emissione di \const{SIGTTOU} come
illustrato in sez.~\ref{sec:sess_ctrl_term}.\footnote{con la stessa eccezione,
- già vista per \func{tcsetaddr}, che quest'ultimo sia bloccato o ignorato dal
+ già vista per \func{tcsetattr}, che quest'ultimo sia bloccato o ignorato dal
processo chiamante.}
Una prima funzione, che è efficace solo in caso di terminali seriali asincroni
\end{description}
-%
-% Qui c'è da mettere tutta la parte sui terminali virtuali, e la gestione
-% degli stessi
-%
\section{La gestione dei terminali virtuali}
\label{sec:sess_virtual_terminal}
+%
+% TODO terminali virtuali
+% Qui c'è da mettere tutta la parte sui terminali virtuali, e la gestione
+% degli stessi
+%
+
Da fare.
\subsection{I terminali virtuali}
projects / gapil.git / blobdiff