Newsgroup: it.comp.os.linux.development
Titolo: bash - quesito sulle pipe

l'ho gia' posto in un altro ng, ma non ho avuto risposta
qualcuno forse mi sa chiarire?
la cosa e' talmente strana, da sembrare persino incoerente...
$ echo 123 > fifo &
[1] 1691
$ echo 456 > fifo &
[2] 1698
$ read -n3 < fifo &
[3] 1713
[1]   Done                    echo 123 >fifo
[2]-  Done                    echo 456 >fifo
[3]+  Done                    read -n3 <fifo
cioe', piu' processi possono accodare il loro output ad una pipe
ma solo un processo puo' leggerla... quando quest'unico processo esce, 
che abbia letto tutto o meno, la pipe viene svuotata lostesso, e nessun 
altro processo puo' leggere quello che resta..
perhe'?

 altro processo puo' leggere quello che resta..
Copio ed incollo dalla pagina man di pipe, il corrispondente C di
fifo:
If all file descriptors referring to the read  end  of  a  pipe  have
been closed,  then  a  write(2) will cause a SIGPIPE signal to be
generated for the calling process.  If the calling process is ignoring
this signal, then write(2) fails with the error EPIPE
Se vuoi leggere l'output in sequenza da processi diversi, racchiudili
in un unico processo (es. uno script).
--
enos76

creado di aver capito la questione
ogni processo che usa una pipe, quando esce la chiude
e quando la pipe viene chiusa, diventa vuota
e' possibile eseguire il secondo echo su pipe...
echo 123 > fifo &
echo 456 > fifo &
perche' il primo non e' ancora uscito, e quindi la pipe e' ancora aperta
in teoria e' possibile anche il contrario, ovvero avere due letture con 
due processi diversi... purche' si riesca a lasciare la prima lettura 
'appesa', senza farla uscire
$ dd if=fifo bs=1 count=3 &
[1] 8921
$ dd if=fifo bs=1 count=3 &
[2] 8922
$ echo -n "123456" > fifo
$ 1233+0 records in
3+0 records out
3 bytes (3 B) copied, 2.9527e-05 seconds, 102 kB/s
4563+0 records in
3+0 records out
3 bytes (3 B) copied, 2.371e-05 seconds, 127 kB/s
[1]-  Done                    dd if=fifo bs=1 count=3
[2]+  Done                    dd if=fifo bs=1 count=3

 e quando la pipe viene chiusa, diventa vuota [...]
Mmmmh... no.
Hai letto il testo che ho incollato? Quando il processo che legge la
pipe si chiude, la pipe non si chiude, ma lancia un segnale SIGPIPE ai
processi che ancora scrivono. Se questi processi non catturano il
segnale, la loro scrittura fallisce.
--
enos76

 segnale, la loro scrittura fallisce.
si, ma non e' che abbia capito bene
i processi che possono leggere e scrivere su una pipe sono piu' d'uno... 
mentre da come ne parli tu (e da come ne parla man) sembra ci si 
riferisca ad uno solo
quando l'ultimo dei processi che legge termina, che abbia letto tutto o 
meno, invia un segnale a _tutti_ i processi che ci stanno scrivendo su?
quindi sono i processi 'scriventi' a possedere la pipe, ma i processi 
'lettori' che ne decretano la fine?
eppure, se io interrompo un processo che sta scrivendo su una pipe, si 
interrompe anche quello che sta leggendo...

 Mmmmh... no.
come no...
quello che scrive, manda un EOF
quello che legge manda un SIGPIPE
entrambi, quando finiscono, fanno chiudere tutta la pipe
e questa ritorna ad essere vuota, indipendentemente da quello che ci 
poteva esser ancora scritto

 
ma poi... che carattere e' EOF?
credevo fosse \x04, ma...
$ echo "OK"$'\x04'"KO" > fifo &
[1] 14342
$ cat fifo
OK KO
[1]+  Done                    echo "OK"' '"KO" >fifo
... cat se l'e' letto senza fermarsi.
(com'e' difficile la vita... :)

 'lettori' che ne decretano la fine? [...]
Da come l'ho capita, la pipe e' "posseduta" da chiunque la usi, e
finisce solo quando l'ultimo (lettore o scrivente) la molla. Gli
scriventi la mollano o quando hanno finito di scrivere, o quando
ricevono segnali di errore critici o che non sono preparati a gestire.
I lettori la mollano o quando decidono, o in caso di errore, o forse
come dici tu anche in caso di EOF, ma quest'ultima chiusura potrebbe
dipendere da come il programma lettore gestisce EOF (in quest'ultimo
caso rientrerebbe anche l'interruzione di scrittura di cui parli, che
fa chiudere il programma che legge quando le scritture finiscono). Non
mi esprimo per l'ultimo caso, faro' delle prove in C.
Cosi' e' come mi immagino la situazione: i lettori dicono solo
"abbiamo finito" e mollano la pipe. Restano gli scriventi.
Linux dice agli scriventi: non c'e' nessuno che legge, avete capito?
Se quelli rispondono "si, ma non ci interessa, aspettiamo", possono
continuare a scrivere, aspettando fermi fino a che qualcun altro
inizia a leggere. Altrimenti se i processi scriventi non rispondono a
linux, lui dice "la festa e' finita, tutti a casa", e chiude la pipe.
Se non sono stato chiaro, dimmelo, potrebbe anche essere che mi
sbagli. Postero' i programmi in C se riesco a dimostrare o smentire la
mia tesi.
Ciao
--
enos76

 linux, lui dice "la festa e' finita, tutti a casa", e chiude la pipe.
e credo valga anche l'opposto
gli scrittori dicono "abbiamo finito" e mollano la pipe... ma senza 
passare per linux... mandano un EOF
(ovvio... loro stanno gia' comunicando dati all'altro processo... che 
gli frega a loro di usare i segnali)
poi immagino che il lettore possa anche ignorare l'EOF, e restare in 
attesa che qualcuno riinizi a scrivere... proprio come lo scrittore puo' 
intercettare il SIGPIPE...
pero' in bash le cose restano sempre un po' oscure
dovrei passare il C, ma sono ancora troppo giovane... :)