Arg... je débute en C, et pour débuter, je commence par un petit programme (Dock WindowMaker) simple de "monitoring" pour le client Genome@home  (seti@home like): http://gah.stanford.edu  
Mais j'ai un petit problème, certainement trés simple, mais je n'arrive pas à le résoudre.
Lorsqu'on lance le client dans un shell, j'ai une sortie à l'écran, qui affiche l'état d'avancement... et notament le pourcentage (par 10%) d'avancement d'une sequence (il y a 30 sequences en tout).... et je n'arrive pas à récuperer cette info (la dernière ligne que le client à envoyé à l'écran) !!!
Même en lançant le client dans un shell en faiseant une redirection vers un fichier ... rien !!? (juste les indications de départ ,la sequence, puis plus rien !!?).
Une solution ? (en C ou en shell bash).
Merci.

La sortie du prog se fait peut-être sur 'stderr' ...

pas mieux
 
j' essai déjà depuis le shell (avant d'attaquer en C):
./ghclient.x > rapport.txt
./ghclient.x 1> rapport.txt
./ghclient.x 2> rapport.txt
ne me donnent rien !!!
 
Voilà la sortie écran lorsque je lance le client:
####################################################
####################################################
 
     Genome@Home Virtual Genome Client
 
     http://genomeathome.stanford.edu
     email:help@genomeathome.stanford.edu
 
####################################################
####################################################
version 0.93
 
Client ID is 6690955129112392134
 
Looking for unsent finished work . . .
No results found, continuing . . .
 
Check current work status . . .
0 superloops completed
1 subloops completed
You have unfinished work from a previous session.
 
Genome@home starting at sequence 2
 
 
Your current protein is: SH3/pdb1azg.2.spa
See http://genomeathome.stanford.edu/p [...] 1azg.2.spa
for information about this protein
   
 Initializing protein design algorithm
 Designing protein sequence 2  of 30
 10.0 %  
 20.0 %
 etc...  
 
Voilà ce que j'ai avec les redirections:  
####################################################
####################################################
 
     Genome@Home Virtual Genome Client
 
     http://genomeathome.stanford.edu
     email:help@genomeathome.stanford.edu
 
####################################################
####################################################
version 0.93
 
Client ID is 6690955129112392134
 
Looking for unsent finished work . . .
No results found, continuing . . .
 
Check current work status . . .
0 superloops completed
1 subloops completed
You have unfinished work from a previous session.
 
Genome@home starting at sequence 2
 
 
Your current protein is: SH3/pdb1azg.2.spa
See http://genomeathome.stanford.edu/p [...] 1azg.2.spa
for information about this protein
 
et voilà...cela s'arrête ici !!! rien de plus

 
C'est probablement ce qui se passe a mon avis.
 
Si tu es en Korn Shell,
./ghclient.x > rapport.txt 2>&1
redirigera la sortie de stderr dans stdin qui est redirige dans rapport.txt (l'ordre des redirections est important ici).
A+,

 
Oups... en Korn-Shell la syntaxe "2>&1" ne redirige pas la sortie d'erreur vers stdin mais vers le même flux que stdout.
Ce qui fait qu'on peut faire une opération du genre:
 
programme1 2>&1 | programme2
 
et le pipe lit redirige bien stdout du programme1 vers stdin du programme2. La séquence est équivalente à:
 
mkpipe       &3     &4
programme1   1>&3 3>&-   2>&1 &
programme2   0>&4 4>&-
 
Sinon en général, il n'est pas requis d'utiliser un shell pour faire cette redirection de stdout et stderr du programme1 directement depuis programme2: il suffit que programme2 fasse un fork() pour créer un second processus fils, puis dans le processus fils, qu'il ferme stdout et stderr (qui ont été dupliqués du processus père) et les rouvre en dupliquant stdin (de façon à ce que le fils renvoie les données stdout et stderr vers le même flux que stdin du processus père), puis qu'il ferme stdin du fils ou l'ouvre sur un autre fichier d'entrée si nécessaire, ensuite le processus père peut lire le résultat du processus fils directement depuis son stdin. Le processus fils n'a plus qu'à lancer un exec du programme1.
 
On peut aussi dans le processus père avant de fait un fork créer un pipe (qui possédera deux handles de flux: un d'entrée, un de sortie) avec mkpipe(). Puis on fork(), ce qui duplique ces deux flux dans le processus fils. Le fils ferme alors le flux de lecture du pipe, et le père ferme le flux d'écriture dans le pipe. Ensuite le fils ferme stdout (handle 1) et stderr (handle 2) et les rouvre en dupliquant le handle d'écriture dans le pipe. Si le programme1 n'a pas besoin de lire depuis stdin on peut laisser stdin dupliqué dans le fils. Mais on peut effectuer la même redirection depuis un autre pipe du père au fils. Ensuite le fils n'a plus qu'à faire un exec() du programme1, et le père (qui exécute programme2) peut lire les données du fils depuis le handle de lecture du pipe qu'il a créé. Si le fils se termine, le pipe sera brisé, et le père en sera averti par un erreur PIPE_BROKEN en lisant dans le pipe qui devait renvoyer la suite des messages de sortie et d'erreur du fils.

[edit]--Message édité par verdy_p--[/edit]

Oui, c'etait un lapsus calami: je voulais dire que ca redirigeait stderr dans stdout (et non pas stdin).
A+,

Eventuellement et si tu n'as pas de reponses, tu peux demander a MiniCooler (generalement present sur le forum seti de hardware.fr) comment il a fait pour son SetiCommander...  
 
Tu peux aussi essayer de contacter MashRinx, membre des Team Primordial Soup et Team Egg Roll (team g@h et f@h chez Ars Technica), egalement auteur des logiciels GenomeVoyeur et FoldingVoyeur qui permettent (entre autres) de monitorer la progression du calcul.  
 
ps: et si ca se trouve, tu ne vas meme pas avoir besoin de faire ton logiciel si ceux ci te conviennent

Salut JWHy .... désolé, je t'ai dis il y a qq temps que je mettais une machine sur f@h ... mais en RTC ... je vais me ruiner  ... alors je reste sur g@h.
 
Je vais encore me creuser la tête pour mon problème (c'est surtout pour estimer le temps... mais je vais essayer de m'y prendre autrement) ... qui ne se pose pas par ailleur avec f@h, car le client créé une sortie sur scrlog.txt.
Quant à GV http://www.zerothelement.com/hosted/gv.shtml  ...euh ...ben ... je tourne sous GNU/linux ... et pis zut ... y'a pas les sources  
et puis, c'est en forgeant qu'on devient forgerons.... sinon j'apprendrai jamais

ah oui pardon... j'avais pas vu le mot "shell"