L'EOF indica di norma il termine di tutto l'input (esattamente come quando arrivi alla fine del file), le utility di cui sopra in genere processano una riga alla volta, e quando arrivano a leggere un EOF escono.
L'EOF indica di norma il termine di tutto l'input (esattamente come quando arrivi alla fine del file), le utility di cui sopra in genere processano una riga alla volta, e quando arrivano a leggere un EOF escono.
Amaro C++, il gusto pieno dell'undefined behavior.
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.
Per fare un tavolo ci vuole un fiore.
None! Non confondere la fine del file con la fine della riga!
Quando finisce la riga viene elaborata e viene sputato l'output1, 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.
Amaro C++, il gusto pieno dell'undefined behavior.
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.)
Ultima modifica di filips; 20-11-2016 a 05:33
Per fare un tavolo ci vuole un fiore.
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).
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.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..
Sta in attesa di stdin. Però attenzione, se usi questi comandi in una pipeline - ad esempio: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.)
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.codice:cat file1.txt file2.txt | sed 's/pippo/pluto/g' | grep 'ciao' | tail
Amaro C++, il gusto pieno dell'undefined behavior.
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)
![]()
Per fare un tavolo ci vuole un fiore.