Newsgroup: it.comp.programmare
Titolo: una strana dup2

Ciao a tutti,
una domanda rapida..
In Microsoft visual c++ l'help online afferma che una chiamata dup2 come
questa
    status = dup2(handle1,handle2)
dovrebbe chiudere il secondo file handle, se associato ad un handle aperto
al momento della chiamata (indipendentemente se sia un file o
stdin/stdout/stderr).
Invece se provo ad effettuare una write() immediatamente, dopo la suddetta
funzione mi restituisce il numero di caratteri scritti (ma dove se handle2
dovrebbe essere chiuso?)
Se invece chiudo manualmente il descrittore di file con close(handle2), la
funzione write mi restituisce -1 (correttamente).
Quindi sembrerebbe che in realtà, contrariamente a quanto riportato
nell'help, la funzione dup2 lasci aperto il secondo handle.
Qualcuno può aiutarmi? Dove sta il trucco?
Grazie mille

 dovrebbe essere chiuso?)
Non è handle2 che è chiuso. E' il file che era associato a handle2 prima
della chiamata ad essere chiuso. Dopo la chiamata handle2 è un secondo
handle che fa riferimento allo stesso file a cui faceva riferimento
handle1.
Questa versione di dup normalmente si usa solo per associare, dopo
l'inizio del programma, un handle predefinito (come lo stdin) a un file
aperto da te. Normalmente per ottenere un secondo handle si usa dup
(senza il 2). Ma è abbastanza raro che tu abbia bisogno di usare dup o
dup2. Cosa cerchi di fare?
--
Andrea Ferro
---------
Brainbench C++ Master. Scored higher than 97% of previous takers
Scores: Overall 4.46, Conceptual 5.0, Problem-Solving 5.0
More info 
http://www.brainbench.com/transcript.jsp?pid=2522556


Ok, credo di essere stato decisamente poco preciso!
 volevo dire che se (come suggerivi tu) al posto di handle2 metto "1"
(stdoutput) non dovrebbe chiudere il file? Non sarebbe stdoutput  il file
associato a handle2 prima della chiamata? Il risultato che ottengo se ci
provo è che dopo la dup2 le funzioni tipo printf (ad esempio) stampano sul
file associato a handle1, come mi aspetterei, ma se io provo a fare una
chiamata di tipo write() specificando esplicitamente lo stdout, questa
funziona ancora.
In effetti il problema (piuttosto ingarbugliato) è il seguente: vorrei
lanciare un programma eseguibile dall'interno di un ambiente di simulazione
di tipo client/server (di cui non ho il sorgente, è un'applicazione
commerciale) derivato da  ptolemy (non so se lo conosci); il fatto è che il
mio eseguibile è basato su una libreria di terza parte che effettua (sigh)
delle scritture di "debug" su standard output che vanno a inchiodare la
comunicazione tra client e server, i quali nel frattempo si stanno
scambiando dei messaggi a intervalli regolari, ad esempio sullo stato della
simulazione, che non possono ovviamente essere disattivati.
Il tentativo è quello di riuscire a redirigere lo stdout del processo
lanciato da me su di un file di log, da cancellarsi a simulazione terminata,
per evitare che le printf finiscano in pasto al server, che, "poverino", non
riconosce i dati ricevuti come messaggi validi, incartandosi puntualmente.
Pensavo di aprire due pipe, e di passare gli handle di lettura e scrittura
al processo figlio chiamato con una spawnl() come parametri di argv[]. Che
tu sappia (scusa l'ignoranza), su una pipe posso scrivere solo un valore
(char , int ecc) alla volta o posso fare un fflush di un buffer intero?
PS Grazie per l'aiuto
Giancarlo

 (char , int ecc) alla volta o posso fare un fflush di un buffer
intero?
Non so se lavori sotto unix o sotto windows. Se lavori sotto windows
puoi lanciare un processo specificando esplicitamente i vari handle da
usare per l'IO standard. Se vuoi ridirezionare stdout su file non ti
serve neppure una pipe ma basta che apri un file e gli passi l'handle di
quello.
Comunque le pipe dovrebbero essere trattabili come comuni file. Non so
sotto unix ma sotto windows hanno un handle che puoi usare ovunque sia
accettato un handle di file.
Però ovviamente stiamo parlando di handle windows (nel sorgente HANDLE e
non int). E le funzioni sono quelle delle API. Non quelle del C/C++.
