una istanza di questo programma su un terminale, il tutto ripetuto per
ciascuno dei terminali che si hanno a disposizione (o per un certo numero di
essi, nel caso delle console virtuali), secondo quanto indicato
-dall'amministratore in \file{/etc/inittab}.
+dall'amministratore nel file di configurazione del programma,
+\file{/etc/inittab}.
-Il programma viene lanciato da \texttt{init} con i privilegi di
-amministratore, e con un ambiente vuoto; \cmd{getty} si cura di aprire il
+Quando viene lanciato da \cmd{init} il programma parte con i privilegi di
+amministratore e con un ambiente vuoto; \cmd{getty} si cura di aprire il
terminale in lettura sullo standard input ed in scrittura sullo standard
-output e sullo standard error, di effettuare, qualora servano, ulteriori
+output e sullo standard error, e di effettuare, qualora servano, ulteriori
settaggi,\footnote{ad esempio, come qualcuno si sarà accorto scrivendo un nome
- di login in maiuscolo, può effettuare la conversione in minuscole
- automaticamente, ponendosi in una modalità speciale che non distingue fra i
- due tipi di caratteri (a beneficio di vecchi terminali che non supportano le
- minuscole).} ed infine di stampare un messaggio di benvenuto e porsi in
-attesa dell'immissione del nome di un utente.
-
-Una volta che si sia immesso un nome di login \cmd{getty} esegue il programma
-\cmd{login} con una \func{exevle}, passando come argomento la suddetta stringa
-ed un ambiente opportunamente costruito che contenga quanto necessario (ad
-esempio di solito viene opportunamente inizializzata la variabile di ambiente
-\texttt{TERM}) ad identificare il terminale su cui si sta operando, a
-beneficio dei programmi che verranno lanciati in seguito.
+ 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).} ed infine 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
+suddetta stringa ed un ambiente opportunamente costruito che contenga quanto
+necessario (ad esempio di solito viene opportunamente inizializzata la
+variabile di ambiente \texttt{TERM}) ad identificare il terminale su cui si
+sta operando, a beneficio dei programmi che verranno lanciati in seguito.
A sua volta \cmd{login}, che mantiene i privilegi di amministratore, usa il
nome dell'utente per effettuare una ricerca nel database degli
\func{chdir} per settare la \textit{home directory} dell'utente, cambia i
diritti di accesso al terminale (con \func{chown} e \func{chmod}) per
assegnarne la titolarità all'utente ed al suo gruppo principale, assegnandogli
-al contempo i diritti di lettura e scrittura. Inoltre il programma provvederà
+al contempo i diritti di lettura e scrittura. Inoltre il programma provvede
a costruire gli opportuni valori per le variabili di ambiente, come
\texttt{HOME}, \texttt{SHELL}, ecc. Infine attraverso l'uso di \func{setuid},
\func{setpid} e \func{initgroups} verrà cambiata l'identità del proprietario
\label{sec:sess_net_log}
Nel caso di un login via rete la cosa si fa leggermente diversa, in tal caso
-infatti non essendo possibile prevedere
+infatti non esiste un terminale fisico che \cmd{init} può tenere sotto
+controllo diretto, in quanto il collegamento deve avvenire tramite la rete.
+Quello che succede in questo caso è che nel procedimento di avvio del sistema
+si occupa di eseguire tutti i programmi che attivano la connesione di rete,
+per poi avviare tutti i programmi di servizio.
+
+Questo viene in genere fatto attraverso una serie di script di shell, che
+vengono eseguiti in un preciso ordine (di nuovo la struttura del procedimento
+di avvio di System V va al di là di quanto ci interessa trattare) che
+eseguiranno i programmi richiesti, fra i quali sarà compreso (se
+l'amministratore lo avrà previsto) pure il server per le connessioni di rete.
+
+Quest'ultimo sarà posto in esecuzione e si metterà in ascolto di eventuali
+connessioni sulla rete, una volta che la procedura di avvio sarà completata
+gli script termineranno ed il server si troverà ad avere \cmd{init} come
+processo padre.
\subsection{Il login attraverso X}
attivare all'avvio (sia fondamentali, come il gestore delle fineste, che
effimeri, come un notificatore di posta in arrivo).
-In questo caso q
+In questo caso
+
+
\section{Il \textit{Job control}}
\label{sec:sess_job_control}
terminale,\footnote{con X e con i terminali vituali tutto questo non è più
vero, dato che si può accedere a molti terminali in contemporanea, ma il
sistema è nato prima dell'esistenza di tutto ciò.} avendo cioè un solo punto
-in cui su può avere accesso all'input ed all'output degli stessi.
+in cui si può avere accesso all'input ed all'output degli stessi.
\subsection{La struttura di base}
\label{sec:sess_relation}
-
+Una volta che si è completata la procedura di login illustrata in
+\ref{sec:sess_login} si avrà a disposizione una shell dalla quale eseguire i
+comandi. Come illustrato in \secref{sec:intro_kern_and_sys} in un sistema Unix
+questi non sono altro che programmi come gli altri, inoltre essendo il sistema
+multitasking, non è neanche detto che un programma venga eseguito da un solo
+processo, infatti, oltre all'uso delle pipe, che permette di concatenare più
+con un solo comando, ed i sigoli programmi possono anche creare ulteriori
+sottoprocessi per eseguire alcuni compiti.
+
+Tutti questi processi, che originano da un solo comando iniziale, vengono
+raggruppati in quello che viene chiamato un \textit{process group}; quando
+viene creato ogni
+processo viene infatti mantenuto,
\subsection{I \textit{process group}}
projects / gapil.git / blobdiff