sessione ad un processo è quello di crearne una nuova con l'uso di
\func{setsid}; il suo prototipo è:
\begin{prototype}{unistd.h}{pid\_t setsid(void)}
- Crea una nuova sessione sul processo corrente settandone \acr{sid} e
+ 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 è \macro{EPERM}, che si ha quando il
- \acr{pgid} e \acr{pid} del processo concidono.}
+ \acr{pgid} e \acr{pid} del processo coincidono.}
\end{prototype}
La funzione imposta il \acr{pgid} ed il \acr{sid} del processo corrente al
In genere (a meno di redirezioni) nelle sessioni di lavoro questo terminale è
associato ai file standard (di input, output ed error) dei processi nella
-sessione, ma solo quelli che fanno parte del cosiddetto ragruppamento di
+sessione, ma solo quelli che fanno parte del cosiddetto raggruppamento di
\textit{foreground}, possono leggere e scrivere in certo istante. Per
impostare il raggruppamento di \textit{foreground} di un terminale si usa la
funzione \func{tcsetpgrp}, il cui prototipo è:
\func{waitpid}.} Se però si bloccano o ignorano i due segnali citati, le
funzioni di lettura e scrittura falliranno con un errore di \macro{EIO}.
-Un processo può contollare qual'è il gruppo di \textit{foreground} associato
+Un processo può controllare qual'è il gruppo di \textit{foreground} associato
ad un terminale con la funzione \func{tcgetpgrp}, il cui prototipo è:
\begin{functions}
\headdecl{unistd.h} \headdecl{termios.h}
aver rediretto l'output di accedere al terminale di controllo, pur non
disponendo più del file descriptor originario; un caso tipico è il programma
\cmd{crypt} che accetta la redirezione sullo standard input di un file da
-decrittare, ma deve poi leggere la password dal terminale.
+decifrare, ma deve poi leggere la password dal terminale.
Un'altra caratteristica del terminale di controllo usata nel job control è che
utilizzando su di esso le combinazioni di tasti speciali (\cmd{C-z},
connessione di rete. Dato che i concetti base sono gli stessi, e dato che alla
fine le differenze sono\footnote{in generale nel caso di login via rete o di
terminali lanciati dall'interfaccia grafica cambia anche il processo da cui
- ha origine l'esecuzione della shell.} nel device cui il kernel associa i
+ ha origine l'esecuzione della shell.} nel dispositivo cui il kernel associa i
file standard (vedi \secref{sec:file_std_descr}) per l'I/O, tratteremo solo il
caso classico del terminale.
telescriventi (\textit{teletype}), da cui deriva sia il nome dell'interfaccia,
\textit{tty}, che quello dei relativi file di dispositivo, che sono sempre
della forma \texttt{/dev/tty*}.\footnote{questo vale anche per i terminali
- vitruali associati alle connessioni di rete con \cmd{telnet} o \cmd{ssh}.}
+ virtuali associati alle connessioni di rete con \cmd{telnet} o \cmd{ssh}.}
Per controllare un terminale si usa di solito il programma \cmd{getty} (od una
delle sue varianti), che permette di mettersi in ascolto su uno di questi
\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 effettuarà, qualora servano, ulteriori
+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
iniziali, come la stampa di messaggi di benvenuto o il controllo della posta)
ad eseguire con un'altra \func{exec} la shell, che si troverà con un ambiente
già pronto con i file standard di \secref{sec:file_std_descr} impostati sul
-terminale, e pronta, nel ruolo di leader di sessione e processo di controllo
-per il terminale, a gestire l'esecuzione dei comandi come illustrato in
-\secref{sec:sess_job_control_overview}. Dato che il processo padre resta
-sempre \cmd{init} quest'ultimo potrà provvedere, ricevendo un \macro{SIGCHLD}
-all'uscita della shell, a rilanciare \cmd{getty} sul terminale per ripetere da
-capo tutto il procedimento.
+terminale, e pronta, nel ruolo di leader di sessione e di processo di
+controllo per il terminale, a gestire l'esecuzione dei comandi come illustrato
+in \secref{sec:sess_job_control_overview}.
+
+Dato che il processo padre resta sempre \cmd{init} quest'ultimo potrà
+provvedere, ricevendo un \macro{SIGCHLD} all'uscita della shell quando la
+sessione di lavoro è terminata, a rilanciare \cmd{getty} sul terminale per
+ripetere da capo tutto il procedimento.
Come sottolineato fin da \secref{sec:intro_base_concept}, in un sistema
unix-like tutte le operazioni sono eseguite tramite processi, comprese quelle
-operazioni di sistema (come l'esecuzione di comandi periodici, o la consegna
+operazioni di sistema (come l'esecuzione dei comandi periodici, o la consegna
della posta, ed in generale tutti i programmi di servizio) che non hanno a che
fare con la gestione diretta dei comandi dell'utente.
-Questi programmi, che devono essere eseguiti in modalità non interattiva senza
-nessun intervento dell'utente, sono normalmente chiamati \textsl{demoni}, (o
-\textit{daemons}), nome ispirato dagli omonimi spiritelli che svolgevano vari
-compiti, di cui parlava Socrate (che sosteneva di averne uno al suo
-servizio).\footnote{NdT. ricontrollare, i miei ricordi di filosofia sono
- piuttosto datati.}
-
+Questi programmi, che devono essere eseguiti in modalità non interattiva e
+senza nessun intervento dell'utente, sono normalmente chiamati
+\textsl{demoni}, (o \textit{daemons}), nome ispirato dagli omonimi spiritelli
+che svolgevano vari compiti, di cui parlava Socrate (che sosteneva di averne
+uno al suo servizio).\footnote{NdT. ricontrollare, i miei ricordi di filosofia
+ sono piuttosto datati.}
+
+Dato che un demone deve essere eseguito non interattivamente, esso non può far
+parte di una sessione e non deve avere un terminale di controllo, per questo
+motivo occorre prendere gli opportuni provvedimenti perché il sistema del
+\textit{job contol} non interferisca.