Newsgroup: it.comp.os.linux.iniziare
Titolo: Stampare su file e salvare

Scusate la domanda stupida, ma ci sto impazzendo da un'oretta e non trovo
niente al riguardo.
Ho scritto un applicazione e ho bisogno che mi stampi su un file .txt quello
che invece dovrebbe apparire nel terminal.
Cosě avevo pensato a qualcosa come ./applicazione > file.txt
In effetti per un applicazione che ad un certo punto termina, tutto va bene,
mentre per un'altra che rimane "in attesa" e autonomamente non esce mai, nel
momento in cui poi faccio Control+C per uscire e osservarne i risultati, mi
ritrovo che non ha stampato (salvato) nulla. O meglio, il file.txt esiste ma
č bianco.
Credo che dipenda dal modo che ho "brusco" di interrompere l'applicazione.
Esiste un modo che la interrompa "salvando" sul file quello che avrebbe
dovuto stampare fino a quel momento?
Scusate se sono stato contorto ma sono agli inizi con Linux e mi manca il
vocabolario :)))
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 dovuto stampare fino a quel momento?
Dovrebbe essere automatico.
In ogni caso, puoi anche provare a sostituire il ^C con un kill del
processo, magari usando segnali diversi (io comincerei con un "kill -1").
Ciaom
-- 
        Roberto Divia`              Love at first sight is one of the greatest
Dep:PH Bat:53 Mailbox:C02110      labour-saving devices the world has ever seen
Route de Meyrin 385               ---------------------------------------------
Case Postale                                Phone:  
+41-22-767-4994
CH-1211 Geneve 23 CERN                      Fax:    
+41-22-767-9585
Switzerland                                 E-Mail: 
Robert...@cern.ch

 fino a quel momento?
Certo, imparare a programmare.
Scherzi a parte, per terminare in modo pulito
un'applicazione si mandano opportuni segnali al
processo tramite kill.
Però il programma deve essere fatto in modo 
da intercettare questi segnali e terminale in 
modo pulito.

 è bianco.
mah, senti a me sembra un gran porcaio.
i file falli aprire alle due applicazioni dal codice, usando tecniche di
lock/unlock per poter prendere il descrittore e scriverci. ah, un handler
dei segnali che lanci per uccidere la prima (sigkill per per chiudere il
descrittore, sigusr per un eventuale secondo metodo di passaggio del
descrittore) non farebbe male.
ciao

 che hai scritto.
cmq non è un baco. deve rimanere in attesa.

 qualche idea sul perchè si comporti in questo modo,...
Di idee ne ho molte ma se non dai tutte le informazioni 
per replicare il problema sono inutili.
 

 per replicare il problema sono inutili.
Non so a cosa possa servirti, comunque ti spiego:
Applicazione 1 e Applicazione 2.
L'Applicazione 2 si mette in attesa. Ogni 5 secondi (ad esempio) stampa un
messaggio che avvisa dell'arrivo della deadline
L'Applicazione 1 fa in modo che si verifichi un evento, in tal caso
l'Applicazione 2 stampa a video determinati parametri.
A me serve semplicemente salvare su un file quello che viene stampato a
video. Non ho proprio capito cosa centri come è fatta l'applicazione. Non
credo abbia molta importanza.
Ripeto, se ci sono soluzioni che richiedono la modifica del codice,
ringrazio ma non servono, purtroppo. Non posso modificare il codice più di
tanto e credo che la strada sulla quale ero fosse pratica e semplice.
L'unico problema che ho riscontrato è quello di cui vi ho chiesto.
L'ho scritto sul NG perchè magari qualcuno che ha esperienza in merito a
questa " > " si sarà accorto dell'inconveniente e potrà darmi qualche
indicazione su come killare l'Applicazione 2 facendo in modo che venga
salvato l'output sul file.
Se mi puoi essere d'aiuto ti sono grato, altrimenti grazie lo stesso.

 importanza...
Invece ha una certa importanza: se per esempio un programma
usa le ncurses e ne redirigi l'output si puo` verificare
esattamente il comportamento da te descritto.
Ossia:
il programma apparetemente e` bloccato e non produce output.
Ma non e` vero, e` solo un effetto ottico.
In tal caso il baco e` l'uso delle ncurses ;)

 Cosa vuol dire ad esempio?
Che la deadline č variabile (la sceglie l'utente come input). Perciň ho
scritto "ad esempio" ma, in effetti, durante l'esecuzione la deadline č
sempre la stessa. Quindi, se inserisco 5, stampa il messaggio che č arrivata
la deadline ogni 5 secondi e rimane in attesa.
Poi:
l'applicazione funziona bene. Se non indirizzo l'output verso nessun file, e
quindi stampa a video, tutto va regolarmente.
come lo avvio l'ho scritto nel primo post:
comunque
se l'avvio cosě:
./nomeapplicazione
mi stampa a video quello che deve stampare.
Mettiamo che quello che stampa č
"stampa1...
stampa2...
stampa3..."
una riga ogni 5 secondi
Da quanto ho capito, se scrivessi:
./nomeapplicazione > nomefile.txt
queste righe
"stampa1...
stampa2...
stampa3..."
dovrebbe salvarle nel nomefile.txt
E in effetti succede proprio questo quando eseguo l'Applicazione 1 che, dopo
10 eventi, termina autonomamente.
L'Applicazione 2, invece, che rimane in ascolto, non termina mai se non con
un Control+C e, purtroppo, quando la interrompo, non ha salvato nulla di
quello che stampava a video. Ne ho dedotto che, la " > " funzionando per
l'applicazione 1 e non per l'applicazione 2, aveva problemi con
l'interruzione del processo.
Ne ho fatto quindi la controprova, provando a usare Control+C anche durante
l'esecuzione di Applicazione 1 (che prima salvava l'output correttamente nel
file txt) e, in effetti, interrompendola bruscamente, non salvava
neanch'essa la stampa sul file.
Ed č per questo che sono cosě sicuro di quello che dico. L'inconveniente č
semplice e la causa č chiara. La soluzione immagino quindi sia ugualmente
banale. Basta saperla :)

 ...
Tutte informazioni interessanti ma sono solo 
una ripetizione di quanto detto.
Mancano le informazioni importanti in particolare:
Come effettua l'output il secondo programma?
Il resto e` tutta fluffa.

> Come effettua l'output il secondo programma?
con dei printf
E' C

 E' C
Finche' un programma effettua le operazioni di 
uscita su standard output tramite le funzioni di 
libreria printf(), putchar() e puts() la redirezione
funziona ed anche molto bene.
Pero` se mescoli input ed output tramite getchar(), 
scanf() e simili puoi vere grossi problemi con la
bufferizzazione.
Il problema si risolve con il debug del tuo programma.
Ti consiglio di spostarti su icol.development

 Il problema si risolve con il debug del tuo programma.
E mettendo la gestione dei signal con close dei flussi aperti
-- 
           |Save our planet!
    Ciao   |Save wildlife!
   roberto |For your E-MAIL use ONLY recycled Bytes  !!
           |roberto poggi   
rpo...@softhome.net

 aperti
Esagerato!
Esiste anche fflush()


Beh, non sottilizziamo. :-)
Come li chiudi non e' oggetto del contendere.
L'importante e' che il ctrl-c sia gestito, e non butti il bimbo
assieme all'acqua sporca.


 bimbo assieme all'acqua sporca.
Si' condivido.
Forse mi sono espresso male; spero di aver chiarito.

 invocherei fflush() prima di sleep().
Beh, se e' per questo, per eventi cosi' rari nel tempo, io
flusherei ad ogni scrittura, e poi possono arrivare tutti i
segnali che vuoi.
