[C] logica di fgets()

[MItaly]

Lascia perdere un attimo la tastiera; siamo d'accordo che se leggi un file da disco non è la stessa cosa la fine della riga e la fine del file?

[filips]

Sicuramente, visto che in quel caso \n può essere parte dei dati. EOF dice che è terminato. Quindi avevo capito male: non intendevi una sequenza tipo testo\nEOF da tastiera visto che non avrebbe senso un Enter seguito da un ctrl+D. Intendevi forse o Enter o EOF. Resta oscura però la utilità di EOF in un input da riga di comando. E la differenza? \n dice che è terminato e si deve mettere il null.

[MItaly]

Sicuramente, visto che in quel caso \n può essere parte dei dati. EOF dice che è terminato.

Ecco, con l'input da tastiera è esattamente la stessa cosa. Quando premi Enter viene inserito un newline nello stream; l'unica differenza è che le fread/fgets/... su file devono aspettare il disco prima di restituire i dati, mentre da tastiera devono aspettare l'utente (nello specifico, devono aspettare che l'utente inserisca una riga completa e prema Enter, dato che l'input da tastiera è line-buffered) - in altre parole, è solo questione di tempo di attesa e modalità di buffering.

Quando da tastiera inserisci Ctrl-D (su Linux)/Ctrl-Z (su Windows) seguito da un Enter si tratta semplicemente di una convenzione con il programma che ti mostra la console - la sequenza di tasti Ctrl-D+Enter viene tradotta in una chiusura dello stream, per cui "dall'altro lato" il programma vede che lo stream è terminato.

Infine, lo standard input può benissimo essere un file vero e proprio - è quello che succede quando si redirige l'input (ad esempio da console fai tuoprogramma < input_file.txt); in questo caso puoi tranquillamente incontrare un EOF "vero", indipendentemente dai newline.

[filips]

Quando da tastiera inserisci Ctrl-D (su Linux)/Ctrl-Z (su Windows) seguito da un Enter si tratta semplicemente di una convenzione con il programma che ti mostra la console - la sequenza di tasti Ctrl-D+Enter viene tradotta in una chiusura dello stream, per cui "dall'altro lato" il programma vede che lo stream è terminato.

Oh.. Ora mi è chiaro: sequenza di tasti, quindi tutti e tre in in unica soluzione.. Il fatto è che non avevo mai sentito di questa cosa. In pratica aggiungendo ctrl-D/Z si aggiunge l'informazione di fine stream. Non vedo tuttavia l'utilità ai fini pratici in un input da tastiera (ma questo sicuramente dipende da mia inesperienza).

Infine, lo standard input può benissimo essere un file vero e proprio - è quello che succede quando si redirige l'input (ad esempio da console fai tuoprogramma < input_file.txt); in questo caso puoi tranquillamente incontrare un EOF "vero", indipendentemente dai newline.

Infatti, solo che nella guida non lo prendeva in considerazione , visto che i file li trattava più avanti.

Ti ringrazio per queste risposte molto articolate.

[MItaly]

Oh.. Ora mi è chiaro: sequenza di tasti, quindi tutti e tre in in unica soluzione.. Il fatto è che non avevo mai sentito di questa cosa. In pratica aggiungendo ctrl-D/Z si aggiunge l'informazione di fine stream. Non vedo tuttavia l'utilità ai fini pratici in un input da tastiera (ma questo sicuramente dipende da mia inesperienza).

È comodo perché consente di usare gli stessi programmi sia per input da file che per input da tastiera; ad esempio, la maggior parte delle 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. In questa maniera li puoi usare sia per leggere dati da file (usando la redirezione dello standard input), sia in pipeline complesse, sia per leggere dati da tastiera.

Ti ringrazio per queste risposte molto articolate.

[filips]

In pratica mi stai dicendo che programmi impostati a terminare la fase d'acquisizione con l'EOF, possono essere sfruttati con input da tastiera tramite ctrl-D/Z-Enter (omologando così a input da file).

Non capisco però una cosa, il fatto che le utility che hai menzionato agiscano sempre e soltanto sulla base dell'EOF.. Infatti mi sembra che per esse vada anche un semplice Enter per attivarle da tastiera (e quindi senza che vi sia un EOF)

[MItaly]

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.

[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.)