[C] logica di fgets()

[filips]

L'EOF indica di norma il termine di tutto l'input (esattamente come quando arrivi alla fine del file)

Quello che volevo dire e che mi sfugge è questo: ma allora EOF è sempre verificato, anche con input da tastiera + (solo) Enter? Questo viene da chiedersi se è vero che le utility son impostate a fermarsi SOLO in presenza di EOF. Io pensavo/penso che con un input da tastiera + Enter, esse fossero implementate per accorgersi della terminazione tramite il newline, che deve essere qualcosa di diverso dalla EOF, visto che per inserire questa informazione (EOF) si è detto che appositamente esiste Ctrl+D/Z.

[MItaly]

Quello che volevo dire e che mi sfugge è questo: ma allora EOF è sempre verificato, anche con input da tastiera + (solo) Enter? Questo viene da chiedersi se è vero che le utility son impostate a fermarsi SOLO in presenza di EOF. Io pensavo/penso che con un input da tastiera + Enter, esse fossero implementate per accorgersi della terminazione tramite il newline, che deve essere qualcosa di diverso dalla EOF, visto che per inserire questa informazione (EOF) si è detto che appositamente esiste Ctrl+D/Z.

None! Non confondere la fine del file con la fine della riga!
Quando finisce la riga viene elaborata e viene sputato l'output¹, quando si raggiunge EOF (fine file) il programma esce; la cosa è molto diversa!

1. in realtà non è neanche così, o meglio, per utility che lavorano nativamente a riga - tipo sed o head - può essere che facciano fgets o cose del genere, per utility tipo cat il fatto di vedere le risposte riga per riga quando si opera da tastiera è solo un effetto del line buffering attuato su stdin in maniera automatica quando stdin è collegato ad una console.

[filips]

Essendo ormai in ballo, vorrei capire come si deve.

L'equivoco credo sia dipeso da questa affermazione:

utility Unix (cat, sed, head, tail, less, sort, grep, ...) di base si limitano a leggere dati da standard input (che di default è agganciato alla tastiera), processandolo fino a quando incontrano un EOF

che mi aveva dato l'impressione che fossero realizzate per eseguire il processamento dei dati SEMPRE in funzione dell EOF (vedi "processandolo fino a quando incontrano EOF").

Per via di questo fatto mi ero chiesto: ma se l'input arriva con solo l'Enter, come faranno ad accorgersi della sua terminazione?

In base alla tua ultima risposta, questo dovrebbe essere smentito, le utility (e in generale un programma) per eseguire l'elaborazione non richiedono necessariamente un EOF (mi preva bene..) ma una logica del tipo line buffering, quella che in genere si vede operando con esse a console.

Adesso però ho questo dubbio:

Quando finisce la riga viene elaborata e viene sputato l'output1, quando si raggiunge EOF (fine file) il programma esce

Cosa significa? Che senza un EOF il programma non termina, cioè inserendo con un Enter, ottengo l'output ma il programma continua a girare. Mi sembra molto strano.. Ogni volta che in passato ho usato sequenze di comandi a console con solo Enter questi poi restavano caricati accumulandosi in sequenza fino alla mia uscita dalla console?? O forse vuol dire semplicemente che esso resta in attesa di ulteriore line buffered stdin? (In tal caso allora sarebbe tutto chiaro.)

[MItaly]

In base alla tua ultima risposta, questo dovrebbe essere smentito, le utility (e in generale un programma) per eseguire l'elaborazione non richiedono necessariamente un EOF (mi preva bene..) ma una logica del tipo line buffering, quella che in genere si vede operando con esse a console.

Sì, oppure, se non sono agganciate a una console ma ad un file, il buffering può essere di altro tipo (in particolare per utility per cui la riga non ha un valore particolare - ad esempio, cat).

Adesso però ho questo dubbio:

Quando finisce la riga viene elaborata e viene sputato l'output1, quando si raggiunge EOF (fine file) il programma esce

Cosa significa? Che senza un EOF il programma non termina, cioè inserendo con un Enter, ottengo l'output ma il programma continua a girare. Mi sembra molto strano..

Non è strano, è così... se tu da riga di comando dai "cat" senza argomenti questo ti risputerà quello che scrivi in eterno, a meno che tu non dia un EOF.

Ogni volta che in passato ho usato sequenze di comandi a console con solo Enter questi poi restavano caricati accumulandosi in sequenza fino alla mia uscita dalla console?? O forse vuol dire semplicemente che esso resta in attesa di ulteriore line buffered stdin? (In tal caso allora sarebbe tutto chiaro.)

Sta in attesa di stdin. Però attenzione, se usi questi comandi in una pipeline - ad esempio:

cat file1.txt file2.txt | sed 's/pippo/pluto/g' | grep 'ciao' | tail

qui i comandi naturalmente terminano, dato che l'input dell'uno è collegato all'output del precedente, e quindi termina quando il comando precedente termina. cat, terminati file1.txt e file2.txt, esce, chiudendo lo stream di output - per cui sed legge EOF e termina, chiudendo lo stream di output; eccetera.

[filips]

Adesso è tutto chiaro. Avevo interpretato male. Ho fatto pure la prova col cat vuoto.. interessante la precisazione della pipeline. Spero solo che per via del lungo tedio con dubbi e contro-dubbi, in futuro mi fornirai ancora ottime spiegazioni (quella sui virus iniettati in file l'ho messa nel mio archivio digitale)

[MItaly]

Adesso è tutto chiaro. Avevo interpretato male. Ho fatto pure la prova col cat vuoto.. interessante la precisazione della pipeline. Spero solo che per via del lungo tedio con dubbi e contro-dubbi, in futuro mi fornirai ancora ottime spiegazioni

Lieto di averti chiarito la questione

(quella sui virus iniettati in file l'ho messa nel mio archivio digitale)

Uh, onestamente non ricordo... mi linkeresti la cosa?

[filips]

Uh, onestamente non ricordo... mi linkeresti la cosa?

Non ricordi bene, ero io che ricordavo male: http://forum.html.it/forum/showthrea...readid=2912871. Alla prossima e grazie!