[C] Info printf...

[Fire Fox II]

Salve

una info: in un programma, avendo una porzione di codice del genere

.
.
printf("Primo output\n");
printf("Secondo output\n");
.
.
dopo averlo compilato, se provo a redirigere l'output su un file, in questo sarà visualizzato solo il secondo output che ha sovrascritto il primo, nonostante il \n... Why?

Thanks

[fofeppe]

Originariamente inviato da Fire Fox II

Salve

una info: in un programma, avendo una porzione di codice del genere

.
.
printf("Primo output\n");
printf("Secondo output\n");
.
.
dopo averlo compilato, se provo a redirigere l'output su un file, in questo sarà visualizzato solo il secondo output che ha sovrascritto il primo, nonostante il \n... Why?

Thanks

nn vorrei dire una cavolata ma come fai l'output su file??...
prova a scrivere una riga e poi aprire il file facendo append e mettendo la 2°

[Fire Fox II]

Originariamente inviato da fofeppe

nn vorrei dire una cavolata ma come fai l'output su file??...

Beh, dopo averlo compilato con gcc, considerando che viene automaticamente generato il file a.out, digito:

./a.out > test.txt

così otterò l'output direttamente nel file test.txt

prova a scrivere una riga e poi aprire il file facendo append e mettendo la 2°

A dire il vero, più che trovare una soluzione alternativa, vorrei capire quale sia il problema originario...

[fofeppe]

Originariamente inviato da Fire Fox II

Beh, dopo averlo compilato con gcc, considerando che viene automaticamente generato il file a.out, digito:

./a.out > test.txt

così otterò l'output direttamente nel file test.txt



A dire il vero, più che trovare una soluzione alternativa, vorrei capire quale sia il problema originario...

mmh...strano...nn saprei dirti

[RaouL_BennetH]

secondo me, se hai questo problema, qualcosa nel codice non è corretto.

Questo semplice codice:

#include <stdio.h>
       
  int main()
      {
               printf("primo out\n");
               printf("secondo out\n");
      }

se lo redirigo in un file di testo, mi mostra entrambe le righe.

Al limite, prova a compilare così:

gcc nome_tuo_file.c -Wall -o prova

Poi, esegui con: ./prova > testo.txt

[Ziosilvio]

Probabilmente dico una stupidaggine, ma... le stringhe che stampi con printf, finiscono con '\n' o con '\r'?
Perché il comportamento, sembra quello del secondo caso...
In alternativa, potrebbe esserci stata una fopen o una freopen in modalità "w" anziché "a" tra i due printf: ma non mi sembra sia il tuo caso...

Tanto per fare una prova del nove: dopo aver lanciato il programma con l'output rediretto, fai una dir (o un ls -l) sul file test.txt, e controlla la sua lunghezza: se è 15 o 16, allora effettivamente c'è una riscrittura del vecchio file.

[Fire Fox II]

Allora raga, perdonatemi... In effetti, come ha giustamente fatto notare RaouL_BennetH, manca una riga a quella porzione di codice (non me l'ero dimenticata: è che credevo il problema fosse la printf... )
La porzione di codice è :

.
.
printf("Primo output\n");
printf("Secondo output\n");
execlp("echo","echo","Terzo output",NULL);
.
.

Ora l'output visualizzato è solo il terzo: il problema quindi presumo sia la execlp... Ma il parametro \n della printf non dovrebbe fare in modo che la exec esegua dalla terza riga o, almeno, sovrascriva solo la seconda?

[ilsensine]

Aggiungi un fflush(stdout) prima della exec.

[RaouL_BennetH]

Originariamente inviato da Fire Fox II

Allora raga, perdonatemi... In effetti, come ha giustamente fatto notare RaouL_BennetH, manca una riga a quella porzione di codice (non me l'ero dimenticata: è che credevo il problema fosse la printf... )
La porzione di codice è :

.
.
printf("Primo output\n");
printf("Secondo output\n");
execlp("echo","echo","Terzo output",NULL);
.
.

Ora l'output visualizzato è solo il terzo: il problema quindi presumo sia la execlp... Ma il parametro \n della printf non dovrebbe fare in modo che la exec esegua dalla terza riga o, almeno, sovrascriva solo la seconda?

scusa, ma in qualche modo dovresti ripulire l'output prima di execlp.

Sinceramente non so, mi viene in mente fflush ma non so se sia standard

[Fire Fox II]

Si grazie: in effetti funziona "bene" con la flush...

Giusto per capire: perchè è indispensabile usare tale funzione?

[Ziosilvio]

Originariamente inviato da RaouL_BennetH

mi viene in mente fflush ma non so se sia standard

fflush su uno stream di output è standard.

[Fire Fox II]

Originariamente inviato da Fire Fox II

Si grazie: in effetti funziona "bene" con la flush...

Giusto per capire: perchè è indispensabile usare tale funzione?

[ilsensine]

Originariamente inviato da Fire Fox II

Giusto per capire: perchè è indispensabile usare tale funzione?

Sotto linux (e probabilmente tutti i s/o moderni), i "FILE *" sono un layer di astrazione che usano i file descriptor del s/o, che sono i veri "handler" del file (ovvero gli oggetti che hanno significato per il s/o). Quando esegui la exec, il kernel passa al nuovo programma i file descriptor aperti, ma non ha alcuna conoscenza di eventuali FILE * che li utilizzano (in quanto non hanno nulla a che vedere con il kernel, ma sono gestiti dalle librerie in user space). Accade che i FILE * possono avere una loro bufferizzazione interna; quindi se termini (termine improprio) il programma esistente per lanciarne uno nuovo, senza che quello veccio svuoti il buffer, i dati pendenti vanno persi.

Questo però non spiega completamente il comportamento che osservi, in quanto stdout è line-buffered (ovvero l'output viene scritto al termine di una riga). Infatti a me il tuo programma funziona senza flush (_solo_ se l'ultima printf usa un \n); sarebbe interessante sapere perché sul tuo non funziona. Puoi dirmi che s/o stai usando?

[ilsensine]

Originariamente inviato da ilsensine

Sotto linux (e probabilmente tutti i s/o moderni), i "FILE *" sono un layer di astrazione che usano i file descriptor del s/o, che sono i veri "handler" del file (ovvero gli oggetti che hanno significato per il s/o). Quando esegui la exec, il kernel passa al nuovo programma i file descriptor aperti, ma non ha alcuna conoscenza di eventuali FILE * che li utilizzano (in quanto non hanno nulla a che vedere con il kernel, ma sono gestiti dalle librerie in user space). Accade che i FILE * possono avere una loro bufferizzazione interna; quindi se termini (termine improprio) il programma esistente per lanciarne uno nuovo, senza che quello veccio svuoti il buffer, i dati pendenti vanno persi.

Questo però non spiega completamente il comportamento che osservi, in quanto stdout è line-buffered (ovvero l'output viene scritto al termine di una riga). Infatti a me il tuo programma funziona senza flush (_solo_ se l'ultima printf usa un \n); sarebbe interessante sapere perché sul tuo non funziona. Puoi dirmi che s/o stai usando?

Niente mi sono risposto da solo rileggendo il primo post: usi il reindirizzamento su file ( > ), che ha un buffering molto più "aggressivo" di quanto sia normalmente stdout.
Se non vuoi questa bufferizzazione, devi usare le funzioni native del s/o (ad es. write() )

[Fire Fox II]

Originariamente inviato da ilsensine

Se non vuoi questa bufferizzazione, devi usare le funzioni native del s/o (ad es. write() )

Scusa ilsensine se sono recidivo... Sto studiando la funzione exec e sto cercando di capirla per bene... (e mi complimento da solo per il titolo della discussione... ) Vorrei approfittare della tua disponibilità per porti un'altra domanda sempre al riguardo (sperando che non mi banni... )

Compilando tale prog

#include <stdio.h>
       
  int main()
      {
        execlp("echo","echo","Terzo output",NULL);
        printf("Primo output\n");
        printf("Secondo output\n");
      }

indipendentemente dal fatto che l'output si su stdout o su file, ed anche utilizzando la flush dopo la exec, l'output sarà solo il terzo...

Come mai?

[ilsensine]

Originariamente inviato da Fire Fox II

Scusa ilsensine se sono recidivo... Sto studiando la funzione exec e sto cercando di capirla per bene... (e mi complimento da solo per il titolo della discussione... ) Vorrei approfittare della tua disponibilità per porti un'altra domanda sempre al riguardo (sperando che non mi banni... )

Compilando tale prog

#include <stdio.h>
       
  int main()
      {
        execlp("echo","echo","Terzo output",NULL);
        printf("Primo output\n");
        printf("Secondo output\n");
      }

indipendentemente dal fatto che l'output si su stdout o su file, ed anche utilizzando la flush dopo la exec, l'output sarà solo il terzo...

Come mai?

man execlp (prima riga della sezione DESCRIPTION )

[Fire Fox II]

Originariamente inviato da ilsensine

man execlp (prima riga della sezione DESCRIPTION )

Ad essere sincero, è stata la prima cosa che ho fatto...

Ma non sono riuscito cmq a individuare il motivo di tale comportamento...

[ilsensine]

Originariamente inviato da Morkar Karamat

...ed è dovuto alla politica di gestione degli I-Node e del Buffer Cache

Ehm non è così. inode e buffer/page cache vivono solo dentro al kernel, e non sono legati all'esistenza o meno di un processo (e i processi non si devono curare di come quando e perché il kernel decide di effettuare i flush).
Nel problema di Fire Fox II i dati nel kernel non ci arrivano proprio, in quanto gli stream FILE * utilizzano un tipo di bufferizzazione aggiuntivo, completamente gestito in user space. Una strace ti rivelerà che i dati al kernel non vengono mai passati tramite la sys_write, quindi in page cache non ci arrivano mai

Per il primo caso la spiegazione che ti è stata data è corretta, ma vale solo per Unix/Linux (o cmq per Windows no [...] )

Probabilmente anche su windows le cose funzionano in maniera simile, ma non sono osservabili in quanto non esiste il concetto di "sostituire l'immagine di un processo con l'immagine di un altro processo".

[ilsensine]

Originariamente inviato da Fire Fox II

Ma non sono riuscito cmq a individuare il motivo di tale comportamento...

Sotto linux/unix non esiste il concetto di "processo che lancia un altro processo". Esiste il concetto di "processo che decide di terminare la propria esistenza e di continuare come un altro processo", ed è proprio quello che fanno le varie exec.
Quindi, dopo la exec, il processo chiamante (o meglio la sua "immagine") non esiste più; è stato sostituito da un altro. Il pid non cambia, e i descrittori (che vivono in kernel space, quindi sopravvivono alla "distruzione" dell'immagine user space del processo) generalmente vengono lasciati inalterati.