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
+ \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}
\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}
- \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{EINVAL}] Il valore di \param{pgid} è negativo.
+ \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{EINVAL}] il valore di \param{pgid} è negativo.
\end{errlist}
}
\end{prototype}
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
\bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
errore, nel qual caso \var{errno} assumerà i valori:
\begin{errlist}
- \item[\errcode{ENOTTY}] Il file \param{fd} non corrisponde al terminale di
+ \item[\errcode{ENOTTY}] il file \param{fd} non corrisponde al terminale di
controllo del processo chiamante.
- \item[\errcode{ENOSYS}] Il sistema non supporta il job control.
- \item[\errcode{EPERM}] Il \textit{process group} specificato non è nella
+ \item[\errcode{ENOSYS}] il sistema non supporta il job control.
+ \item[\errcode{EPERM}] il \textit{process group} specificato non è nella
stessa sessione del processo chiamante.
\end{errlist}
ed inoltre \errval{EBADF} ed \errval{EINVAL}.
gruppo di \textit{foreground}, e -1 in caso di errore, nel qual caso
\var{errno} assumerà i valori:
\begin{errlist}
- \item[\errcode{ENOTTY}] Non c'è un terminale di controllo o \param{fd} non
+ \item[\errcode{ENOTTY}] non c'è un terminale di controllo o \param{fd} non
corrisponde al terminale di controllo del processo chiamante.
\end{errlist}
ed inoltre \errval{EBADF} ed \errval{ENOSYS}.
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 compiti vari, di cui parlava Socrate (che sosteneva di averne
-uno al suo servizio).\footnote{NdT. ricontrollare, i miei ricordi di filosofia
- sono piuttosto datati.}
+della mitologia greca che svolgevano compiti che gli dei trovavano noiosi, di
+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
\bodydesc{Entrambe le funzioni restituiscono 0 in caso di successo e -1 in
caso di errore, nel qual caso \var{errno} assumerà i valori:
\begin{errlist}
- \item[\errcode{EINTR}] La funzione è stata interrotta.
+ \item[\errcode{EINTR}] la funzione è stata interrotta.
\end{errlist}
ed inoltre \errval{EBADF}, \errval{ENOTTY} ed \errval{EINVAL}.
}
di code di ingresso ed uscita; in generale si fa riferimento ad esse con il
nome di \textsl{discipline di linea}.
-
Lo standard POSIX prevede alcune funzioni che permettono di intervenire
direttamente sulla gestione di quest'ultime e sull'interazione fra i dati in
ingresso ed uscita e le relative code. In generale tutte queste funzioni
sul terminale associato a \param{fd}; un valore nullo di \param{duration}
implica una durata del flusso fra 0.25 e 0.5 secondi, un valore diverso da
zero implica una durata pari a \code{duration*T} dove \code{T} è un valore
-compreso fra 0.25 e 0.5.\footnote{POSIX specifica il comportamento solo nel
- caso si sia impostato un valore nullo per \param{duration}; il comportamento
- negli altri casi può dipendere dalla implementazione.}
+compreso fra 0.25 e 0.5.\footnote{lo standard POSIX specifica il comportamento
+ solo nel caso si sia impostato un valore nullo per \param{duration}; il
+ comportamento negli altri casi può dipendere dalla implementazione.}
Le altre funzioni previste da POSIX servono a controllare il comportamento
dell'interazione fra le code associate al terminale e l'utente; la prima è
\end{table}
+
\subsection{Operare in \textsl{modo non canonico}}
\label{sec:term_non_canonical}
\label{sec:sess_pty}
Qui vanno spiegati i terminali virtuali, \file{/dev/pty} e compagnia.
+% vedi man pts
+
-\subsection{La funzione \func{openpty}}
+\subsection{Allocazione dei terminale virtuali}
\label{sec:sess_openpty}
Qui vanno le cose su \func{openpty} e compagnia.
-
% TODO le ioctl dei terminali
+% TODO trattare \func{posix\_openpt}
+
+
% LocalWords: kernel multitasking dell'I job control BSD POSIX shell sez group
projects / gapil.git / blobdiff