X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=session.tex;h=beb46bbe9bd6323e69ff37d04cfb605d0bd05193;hp=fa9cb13803ae6a9effa07944465c2813138af59f;hb=HEAD;hpb=ae7bf994013ffbf4f5ef1d5a38a18033593e3e9f

diff --git a/session.tex b/session.tex
index fa9cb13..beb46bb 100644
--- a/session.tex
+++ b/session.tex
@@ -1,6 +1,6 @@
 %% session.tex
 %%
-%% Copyright (C) 2000-2018 Simone Piccardi.  Permission is granted to
+%% Copyright (C) 2000-2024 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",
@@ -44,9 +44,9 @@ 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, 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
+a dispositivi specifici lelinee seriali, che in certi casi, come avviene per
+buona parte dei dispositivi embedded su cui gira Linux come router, access
+point, ecc. sono l'unica opzione per una avere una \textit{console} di
 sistema.
 
 
@@ -64,7 +64,7 @@ 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
@@ -562,7 +562,7 @@ terminati.
 L'organizzazione del sistema del job control è strettamente connessa alle
 modalità con cui un utente accede al sistema per dare comandi, collegandosi ad
 esso con un terminale, che sia questo realmente tale, come un VT100 collegato
-ad una seriale o virtuale, come quelli associati a schermo e tastiera o ad una
+ad una seriale, o virtuale, come quelli associati a schermo e tastiera o ad una
 connessione di rete. Dato che i concetti base sono gli stessi, e dato che alla
 fine le differenze sono nel dispositivo cui il kernel associa i file standard
 (vedi tab.~\ref{tab:file_std_files}) per l'I/O, tratteremo solo il caso
@@ -695,12 +695,12 @@ 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
 della mitologia greca che svolgevano compiti che gli dei trovavano noiosi, di
-cui parla anche Socrate (che sosteneva di averne uno al suo servizio).
+cui parla anche Socrate, che sosteneva di averne uno al suo servizio.
 
 %TODO ricontrollare, i miei ricordi di filosofia sono piuttosto datati.
 
 Se però si lancia un programma demone dalla riga di comando in un sistema che
-supporta, come Linux, il \textit{job control} esso verrà comunque associato ad
+supporta il \textit{job control} come Linux, esso verrà comunque associato ad
 un terminale di controllo e mantenuto all'interno di una sessione, e anche se
 può essere mandato in background e non eseguire più nessun I/O su terminale,
 si avranno comunque tutte le conseguenze che abbiamo trattato in
@@ -823,7 +823,7 @@ differenti meccanismi come:
 le modalità con cui queste azioni vengono realizzate dipendono ovviamente dal
 demone che si usa, per la gestione del quale si rimanda ad un testo di
 amministrazione di sistema.\footnote{l'argomento è ad esempio coperto dal
-  capitolo 3.2.3 si \cite{AGL}.}
+  capitolo 3.2.3 di \cite{AGL}.}
 
 La \acr{glibc} definisce una serie di funzioni standard con cui un processo
 può accedere in maniera generica al servizio di \textit{syslog}, che però
@@ -1270,9 +1270,9 @@ al di fuori di questo.
 \label{sec:sess_terminal_io}
 
 Benché come ogni altro dispositivo i terminali siano accessibili come file,
-essi hanno assunto storicamente, essendo stati a lungo l'unico modo di
-accedere al sistema, una loro rilevanza specifica, che abbiamo già avuto modo
-di incontrare nella precedente sezione.
+essendo stati a lungo l'unico modo di accedere al sistema essi hanno assunto
+storicamente una loro rilevanza specifica, che abbiamo già avuto modo di
+incontrare nella precedente sezione.
 
 Esamineremo qui le peculiarità dell'I/O eseguito sui terminali, che per la
 loro particolare natura presenta delle differenze rispetto ai normali file su
@@ -1474,9 +1474,8 @@ essere allocata in precedenza, e la relativa dimensione, \param{len}. Se la
 stringa che deve essere restituita, compreso lo zero di terminazione finale,
 eccede questa dimensione si avrà un errore.
 
-Una funzione funzione analoga alle precedenti prevista da POSIX.1, che
-restituisce il nome di un file di dispositivo, è \funcd{ctermid}, il cui
-prototipo è:
+Una funzione analoga alle precedenti prevista da POSIX.1, che restituisce il
+nome di un file di dispositivo, è \funcd{ctermid}, il cui prototipo è:
 
 \begin{funcproto}{
 \fhead{stdio.h}
@@ -1485,8 +1484,8 @@ prototipo è:
 }
 
 {La funzione ritorna il puntatore alla stringa contenente il \textit{pathname}
-  del terminale o \val{NULL} se non non riesce ad eseguire l'operazione, non
-  sono previsti errori.}
+  del terminale o \val{NULL} se non riesce ad eseguire l'operazione, non sono
+  previsti errori.}
 \end{funcproto}
 
 La funzione restituisce un puntatore al \textit{pathname} del file di
@@ -2201,7 +2200,7 @@ la velocità della linea di trasmissione; se questa non corrisponde a quella
 del terminale quest'ultimo non potrà funzionare: quando il terminale non è
 seriale il valore non influisce sulla velocità di trasmissione dei dati. 
 
-In generale impostare un valore nullo (\val{B0}) sulla linea di output fa si
+In generale impostare un valore nullo (\val{B0}) sulla linea di output fa sì
 che il modem non asserisca più le linee di controllo, interrompendo di fatto
 la connessione, qualora invece si utilizzi questo valore per la linea di input
 l'effetto sarà quello di rendere la sua velocità identica a quella della linea