Discussion :

[zz2f3]

Bonjour,

Je sais comment lancer une commande bash et un programme externe en JAVA :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
try
{
    String commande = "/bin/sh -c ls";
    Runtime runtime = Runtime.getRuntime();
    Process process = null;
    process = runtime.exec(commande);
    process.getInputStream().close();
    process.getOutputStream().close();
    process.getErrorStream().close(); 
 
}catch(Exception err) {;}

Ca marche très bien et je m'en sert aussi pour lancer des programmes...
MAIS !!!
J'ai une application qui s'appelle "Condor" et (sans rentrer dans les détails), pour lancer ce que je veux, il faut que je tape comme commande :

condor_submit fichier_à_envoyer

et tout marche tres bien... le probleme c'est si je lance la commande

/bin/sh -c condor_submit fichier_à_envoyer

mon logiciel bloque au lancement !!!

Comment faire pour contourner ce problème ???

Merci par avance

[tchize_]

pourquoi tu met /bin/sh -c ?? tu peux directement exécuter l'appli sans la passer en argument à un shell.

[zz2f3]

C'est vrai suis-je bete !!!
Merci

Par contre du coup, j'ai un autre problème....
Lorsque je lance ma commande condor_submit fichier_à_envoyer , le logiciel me lance un warning (normal).
Voilà le message que le logiciel affiche "tout à fait normalement..." lorsque je tape la commande dans un shell :

Submitting job(s)
WARNING: Log file /home/rb6141/2june/source/condor_log is on NFS.
This could cause log file corruption and is _not_ recommended.
.
Logging submit event(s).
1 job(s) submitted to cluster 77.


Hors quand je le lance dans JAVA, vu que j'ai mis un try, il croit qu'il y a une erreur et ne le fait pas....
Comment "forcer" le lancement malgrès les warnings ?

[tchize_]

Le try n'a rien à voir là dedans. Le try permet de définir un bloc où tu catch une exception, il défini pas une "zone d'erreur", sans try/catch, l'exception remonte plus haut, mais elle existe toujours. C'est donc pas un try qui va "créer" une erreur. Ton problème, je pense, c'est que tu ferme les input et outpustream, et ton programme il apprécie peut etre pas vraiment. Le mieux, c'est de pomper le process.getOutputStream() et le process.getInputStream() histoire de savoir ce que dit ton programme.

[bouye]

Ah tiens, c'est marrant, tu fais presque la même chose que moi depuis l'an dernier, sauf que moi les submit ont lieu sous Windows. En ce moment je suis entrain d'ailleurs d'essayer de construire une GUI java permettant de monitorer les taches à grand coup de condor_status et de condor_q.

Il te faut consommer ton flux de sortie et ton flux d'erreur plutot que de les fermer. Dans mon cas j'affecte une Thread dédiée à chacun et je recupère ce qu'ils contiennent pour d'éventuels logs, des messages d'erreur ou warnings à afficher à l'utilisateur (dont celui que tu as "perdu" en chemin) et bien sur il faut penser à vérifier le code d'erreur retourné par condor_submit pour savoir si la commande s'est correctement terminée...
Le warning sera probablement contenu dans le flux d'erreur et la ligne indiquant que le job a été correctement soumis dans le flux de sortie standard. Quand au flux d'entrée, il ne sert ici à rien puisque condor est en mode non-interractif mais ca ne sert à rien de le fermer également.

C'est d'ailleurs à partir de ces mêmes classes que je parse et analyse ce que condor_status -long et condor_q -global -long me retournent pour le contenu de ma GUI.