-Tutto ciò ci mostra come sia immediato realizzare un meccanismo di
-comunicazione fra processi attraverso una pipe, utilizzando le proprietà
-ordinarie dei file, ma ci mostra anche qual è il principale\footnote{Stevens
- in \cite{APUE} riporta come limite anche il fatto che la comunicazione è
- unidirezionale, ma in realtà questo è un limite facilmente superabile usando
- una coppia di pipe.} limite nell'uso delle pipe. È necessario infatti che i
-processi possano condividere i file descriptor della pipe, e per questo essi
-devono comunque essere \textsl{parenti} (dall'inglese \textit{siblings}), cioè
-o derivare da uno stesso processo padre in cui è avvenuta la creazione della
-pipe, o, più comunemente, essere nella relazione padre/figlio.
-
-A differenza di quanto avviene con i file normali, la lettura da una pipe può
-essere bloccante (qualora non siano presenti dati), inoltre se si legge da una
-pipe il cui capo in scrittura è stato chiuso, si avrà la ricezione di un EOF
-(vale a dire che la funzione \func{read} ritornerà restituendo 0). Se invece
-si esegue una scrittura su una pipe il cui capo in lettura non è aperto il
-processo riceverà il segnale \const{SIGPIPE}, e la funzione di scrittura
-restituirà un errore di \errcode{EPIPE} (al ritorno del gestore, o qualora il
-segnale sia ignorato o bloccato).
-
-La dimensione del buffer della pipe (\const{PIPE\_BUF}) ci dà inoltre un'altra
-importante informazione riguardo il comportamento delle operazioni di lettura
-e scrittura su di una pipe; esse infatti sono atomiche fintanto che la
-quantità di dati da scrivere non supera questa dimensione. Qualora ad esempio
-si effettui una scrittura di una quantità di dati superiore l'operazione verrà
-effettuata in più riprese, consentendo l'intromissione di scritture effettuate
+Tutto ciò ci mostra come sia immediato realizzare un meccanismo di
+comunicazione fra processi attraverso una pipe, utilizzando le proprietà
+ordinarie dei file, ma ci mostra anche qual è il principale limite nell'uso
+delle pipe.\footnote{Stevens in \cite{APUE} riporta come limite anche il fatto
+ che la comunicazione è unidirezionale, ma in realtà questo è un limite
+ superabile usando una coppia di pipe, anche se al costo di una maggiore
+ complessità di gestione.} È necessario infatti che i processi possano
+condividere i file descriptor della pipe, e per questo essi devono comunque
+essere \textsl{parenti} (dall'inglese \textit{siblings}), cioè o derivare da
+uno stesso processo padre in cui è avvenuta la creazione della \textit{pipe},
+o, più comunemente, essere nella relazione padre/figlio.
+
+A differenza di quanto avviene con i file normali, la lettura da una
+\textit{pipe} può essere bloccante (qualora non siano presenti dati), inoltre
+se si legge da una pipe il cui capo in scrittura è stato chiuso, si avrà la
+ricezione di un EOF (vale a dire che la funzione \func{read} ritornerà
+restituendo 0). Se invece si esegue una scrittura su una pipe il cui capo in
+lettura non è aperto il processo riceverà il segnale \signal{SIGPIPE}, e la
+funzione di scrittura restituirà un errore di \errcode{EPIPE} (al ritorno del
+gestore, o qualora il segnale sia ignorato o bloccato).
+
+La dimensione del buffer della \textit{pipe} (\const{PIPE\_BUF}) ci dà inoltre
+un'altra importante informazione riguardo il comportamento delle operazioni di
+lettura e scrittura su di una pipe; esse infatti sono atomiche fintanto che la
+quantità di dati da scrivere non supera questa dimensione. Qualora ad esempio
+si effettui una scrittura di una quantità di dati superiore l'operazione verrà
+effettuata in più riprese, consentendo l'intromissione di scritture effettuate