[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]

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]

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]

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... :doh: )
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]

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... :doh: )
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? :confused:

[Ziosilvio]

mi viene in mente fflush ma non so se sia standard
fflush su uno stream di output è standard.

[Fire Fox II]

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

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

:)

[ilsensine]

Giusto per capire: perchè è indispensabile usare tale funzione? :confused:
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]

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]

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... :sofico: ) Vorrei approfittare della tua disponibilità per porti un'altra domanda sempre al riguardo (sperando che non mi banni... :D )

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]

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... :sofico: ) Vorrei approfittare della tua disponibilità per porti un'altra domanda sempre al riguardo (sperando che non mi banni... :D )

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]

man execlp (prima riga della sezione DESCRIPTION ;) )

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

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

[ilsensine]

...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]

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.