Visualizzazione dei risultati da 1 a 10 su 24

Discussione: [C] logica di fgets()

Hybrid View

  1. #1
    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.

  2. #2
    Utente di HTML.it L'avatar di filips
    Registrato dal
    Sep 2011
    residenza
    Seconda stella a destra (questo e' il cammino)
    Messaggi
    155
    Quote Originariamente inviata da MItaly Visualizza il messaggio
    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.
    Per fare un tavolo ci vuole un fiore.

  3. #3
    Quote Originariamente inviata da filips Visualizza il messaggio
    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'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.

  4. #4
    Utente di HTML.it L'avatar di filips
    Registrato dal
    Sep 2011
    residenza
    Seconda stella a destra (questo e' il cammino)
    Messaggi
    155
    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.

  5. #5
    Quote Originariamente inviata da filips Visualizza il messaggio
    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:
    codice:
    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.
    Amaro C++, il gusto pieno dell'undefined behavior.

  6. #6
    Utente di HTML.it L'avatar di filips
    Registrato dal
    Sep 2011
    residenza
    Seconda stella a destra (questo e' il cammino)
    Messaggi
    155
    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.

  7. #7
    Quote Originariamente inviata da filips Visualizza il messaggio
    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?
    Amaro C++, il gusto pieno dell'undefined behavior.

Tag per questa discussione

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2025 vBulletin Solutions, Inc. All rights reserved.