|
|
Article complet: Runtime.exec() n'est pas des plus simple...
19/03/2007
, adiGuba [Java] Runtime.exec() n'est pas des plus simple...
L'API Java est assez imposante et complète, mais elle contient toutefois un certain nombre de classe et/ou méthode qui ne sont pas des plus simple à utiliser, ou qui ont un comportement très éloigné de ce que l'on peut trouver dans d'autre langage... ce qui les rends plus complexe et énigmatique.
Si on prend comme exemple le langage C : on peut utiliser les différentes fonctions exec() pour exécuter un programme externe, ou directement la fonction system() pour appeler une commande shell.
Ces fonctions se retrouvent généralement dans la plupart des langages...
Les developpeurs Java connaissent surement l'existence des méthodes Runtime.exec() dont l'objectif est d'exécuter un programme externe représenté par la classe Process. La classe ProcessBuilder de Java 5.0 est peut-être moins connu, mais elle permet grosso-modo la même chose (mais en adoptant une approche un peu plus 'OO').
A première vue on pourrait croire que l'on a affaire à des fonctions/méthodes très similaire, mais il existe pourtant une grosse différence entre l'exécution de programme externe en Java et en C : la gestion des flux d'entrées/sorties !
En effet, lorsqu'on lance un programme externe avec les fonctions exec()/system() du C, les flux d'entrés/sorties du nouveau programme (stdin, stdout et stderr) sont partagés avec le programme appelant. C'est extrêmement pratique puisque les programmes appelés depuis une ligne de commande peuvent interagir directement avec cette dernière.
Or, ce qui marque lorsqu'on lance pour la première fois un Process depuis un programme Java, c'est justement que rien ne semble se passer : la console reste désespérément muette ! En effet ils ne partagent pas leurs flux d'entrés/sorties avec le programme appelant, et ils ne peuvent donc pas lire/écrire directement sur la console.
Au lieu de cela les entrés/sorties standards des Process sont redirigées vers trois flux (getOutputStream(), getInputStream() et getErrorStream()) accessibles par le programme Java.
Et cela pose plusieurs problèmes :
- Premièrement, l'API n'est pas des plus claire à cause de l'inversion des flux : par exemple
getOutputStream()renvoi unOutputStreampermettant d'écrire dans l'entrée standard du Process, etgetInputStream()renvoi unInputStreampermettant de lire la sortie standard... - Secondo, les redirections d'E/S utilisent des buffers de taille limité (et dépendant du système hôte). Si les flux d'E/S ne sont pas traité par le programme appelant, le processus peut se retrouver bloqué. Pire encore : on peut facilement se retrouver dans un cas d'inter-blocage (le processus attend que le programme Java vide le buffer du flux afin de pouvoir continuer son exécution, alors que le programme Java attend que le processus fils se termine pour continuer son exécution, et donc les deux application s'attendent mutuellement).
- Enfin, et toujours pour éviter des inter-blocages, les différents flux doivent être traitées depuis des threads différents, ce qui vient encore compliquer le tout.
Bref : avec comme simple objectif de vouloir lancer un programme, on se retrouve à devoir gérer des lectures de flux et du multithreading...
Un programme n'est pas une ligne de commande
De plus, il faut bien prendre en compte que les méthodes exec() de Java, tout comme les fonctions exec() du C, permettent de lancer un programme, mais pas d'interpréter une ligne de commande ! C'est à dire que le programme appelé doit correspondre à un fichier exécutable, et que chacun des paramètres lui seront passés tel quel sans modification.
En effet, l'interprétation des lignes de commandes fait partie des fonctions du shell, et s'il est possible de l'appeler facilement grâce à la fonction system() du C, il faut malheureusement constater qu'il n'existe aucune équivalence en standard en Java !
Pourtant le shell apporte de nombreux avantages puisqu'il permet d'exécuter des commandes bien plus élaboré :
- La gestion des redirections avec
<,>,>>,2>,2>>et2>&1. - La gestion des pipes de processus avec
|et des opérateurs booléens&&et||. - La gestion des résolutions des variables d'environnements selon la norme du système (
%NAME%sous Windows et$NAMEsous les systèmes Unix). - La gestion des commandes builtins du shell (
echo,cd>, etc.). - Et plus globalement de toutes les spécificités du shell du système d'exploitation hôte, comme l'interprétation des meta-caractères des shell Unix (
*,?,\, etc.)
Bien sûr, la raison est toute simple : l'appel de commande du shell gênerait à la portabilitée de l'application (il faudrait gérer des commandes différentes selon le système cible).
Mais si l'intention est louable, elle est également très problématique car l'appel du moindre programme natif en Java peut devenir un vrai calvaire (ou presque).
Comment faire la même chose en Java ?
Pour arriver à faire la même chose que les fonctions exec() ou system() du C, il faut prendre en compte les spécificité de l'exécution d'application depuis Java, c'est à dire :
Chaque flux doit être traité, c'est à dire que le flux d'entrée doit recevoir des données puis être fermé, et les flux de sortie doivent être lu assez rapidement pour éviter de bloquer le buffer. Le code n'est pas bien compliqué, mais il faut avouer qu'il est assez "pénible" à écrire, surtout à cause du fait que ces lectures/écritures doivent être effectué depuis des threads différents. On peut toutefois simplifier cela en fermant directement les flux qui ne sont pas utilisés...
- On ne peut pas évaluer des lignes de commandes directement, mais il est possible d'appeler le programme représentant le shell système pour qu'il les évalue. Le problème étant que ce même shell dépend du système, c'est à dire par défaut
command.comsous les Windows 9x,cmd.exesous les Windows NT,/bin/shsous les systèmes Unix et assimilé. Mais il peut également y avoir des shells "personnalisé", généralement via les variables d'environnements%ComSpec%sous Windows, ou$SHELLsous Unix...
Ces shells acceptent tous un paramètre/C(sous Windows) ou-c(sous Unix) qui permet d'interpréter une ligne de commande complexe.
Encore une fois ce n'est pas bien compliqué, si ce n'est qu'il faut déterminer le shell système pour tenter d'avoir un tant soit peu de portabilité (même si l'appel de programme externe ou de ligne de commande nuit déjà à la portabilité).
Pour plus de détail concernant l'exécution de programme externe, je vous invite à consulter ce tutoriel : Exécuter une application externe en Java.
Mais il faut avouer que c'est quand même un peu casse pied de devoir faire tout cela rien que pour lancer une application ou une ligne de commande, c'est pourquoi j'ai intégré tout cela dans une API un peu plus simple.
Shell : Une API système pour Java
Voici donc l'API Shell qui permet de simplifier l'exécution de programme et de ligne de commande depuis Java. Elle comporte principalement deux classes :
ProcessConsumerpermet de traiter les flux d'entrées/sorties d'un processus en lui associant des flux via les méthodesinput(),output()eterror(). Elle dispose ensuite de méthodes permettant de lancer le traitement des flux (consume(),consumeInBackground()) voir d'effectuer le traitement en récupérant la sortie standard en tant que chaine de caractères (consumeAsString(),consumeAsStringInBackground()).Mais comme un exemple vaut plus qu'un long discourt, pour utiliser des fichiers comme flux d'entrées/sorties d'un process, on pourrait utiliser ceci :
new ProcessConsumer(process) .input( new FileInputStream("in.txt") ) .output( new FileOutputStream("out.txt") ) .error( new FileOutputStream("err.txt") ) .consume();La méthode
consume()se charge de rediriger les flux vers le process, et de les fermer proprement à la fin du processus.De plus, lorsque les flux de sortie standard et d'erreur ne sont pas spécifié, ils sont redirigés respectivement vers
System.outetSystem.err. Ainsi, ce code affichera le résultat directement sur la console :new ProcessConsumer(process) .input( new FileInputStream("in.txt") ) .consume();Par contre il n'en est pas de même pour le flux d'entrée, car lorsqu'on utilise
System.inen tant que source de données, le thread de lecture se retrouve bloquer si l'utilisateur n'effectue aucune saisie. A ma connaissance, il n'y a pas de moyen de contourner cela étant donné queSystem.inn'est pas "interruptible". Ainsi pour le moment l'utilisation deSystem.incomme source de données pour le flux d'entrée du process provoquera une exception. Par défaut aucun flux d'entrée n'est utilisé.La classe
Shellquand à elle se concentre plus sur l'interaction avec le système. En plus de quelques accesseurs/mutateurs permettant de manipuler des propriétés basiques (répertoire d'exécution, charset, variables d'environnement utilisateur), elle dispose principalement de deux méthodes :command(String)permet d'exécuter une ligne de commande via le shell système. Cette méthode retourne une instance deProcessConsumercorrectement initialisé qu'il suffit d'utiliser.Par exemple pour récupérer en tant que chaine de caractère le retour de la commande
ls | sort(sous un système Unix), il suffit d'utiliser le code suivant :Shell sh = new Shell(); String result = sh.command("ls | sort").consumeAsString();exec()quand à lui fonctionne de la même manière que la méthodeRuntime.exec(), et attend donc un programme valide et non pas une ligne de commande. Elle a toutefois l'avantage de retourner un objet de typeProcessConsumer:String result = sh.exec("monApplicationNative", "param1", "param2").consumeAsString();
Pour finir, il faut noter l'existence de la méthode statique
Shell.system(String)qui permet de lancer une commande en redirigeant directement sa sortie dans la console.
Cette librairie est encore jeune, mal-documenté, risque d'être encore modifiée et doit surement comporter certains bugs. Elle n'a été testé que sous Windows XP et sous Ubuntu Linux mais devrait être compatible avec la plupart des système Windows et Unix (merci de me contacter si ce n'est pas le cas).
Téléchargement
Cette librairie est disponible sous licence CeCILL-C directement sur ces adresses :
- Javadoc online : Javadoc de l'API Shell
- Librairie : Shell.jar
- Sources : Shell-full.zip
Enfin, pour information, l'utilisation d'une librairie sous licence CeCILL-C n'a aucune incidence sur la licence de votre application :
Lorsque vous distribuez une application incorporant des logiciels régis par CeCILL-C, vous devez mettre à disposition de la communauté et soumettre à cette licence les modifications que vous avez apportées au code source des logiciels sous CeCILL-C; cependant vous gardez la liberté de choisir une autre licence, libre ou propriétaire, pour le reste de votre application.
Social Bookmarking:
Adresse de trackback pour cet article:
http://blog.developpez.com/htsrv/trackback.php?tb_id=3035
Commentaires, Trackbacks, Pingbacks:
Article très intéressant, dommage que ce soit un blog :$ J'dis ça parce que je trouve que les blogs sont bien moins accessibles que les articles (ils ne sont pas, notamment et surtout, référencés dans la partie Java, du moins à ma connaissance).
Enfin, j'dis ça, j'dis rien ;)
++
ZedroS
20/03/2007 @ 09:53 Merci parain ;).
20/03/2007 @ 11:17 Je pense que cela aurait été un peu léger pour un article...
Enfin, un article demande bien plus de boulot, et je n'ai pas forcément autant de temps à y consacrer...
Mais si tu veux je garde une liste des billets les "plus intéressants" : http://adiguba.developpez.com/#best_of_blog
a++
20/03/2007 @ 12:09 Je vous salue tout d'abord pour le merveilleux travail,car je suis aussi dans la cadre de travail d'un TP qui consiste à faire des appels des processus extereurs entre autre commande Shell.
Donc votre bloc me serait d'une grande utilité mais cependant des erreurs se sont declarées dans par exemple la classe ProcessConsumer à la premiere compilation .
j'ai developé un premier programme qui me fera ses instruction sans utiliser votre blog mais des erreurs se declare aussi mais voici mon premier programme avec seulement l clase Runtime et Proess,si vous pouvez m'aider:
Le programme devrait permettre d'une maniaire infinie des instructions(commnde en Shell bien "/bin/sh","-c","suivi-commande-voulu") en entrées:J travaille sous Linux(SuSe version 10).....:
import java.io.*;
import java.lang.Process;
import java.lang.System;
import java.lang.Runtime;
import java.lang.Thread;
class threadE1 extends Thread{
public String Line2 ,Line3 = null;
Runtime runtime;
public Process process;
threadE1(String Line1){
Line3=Line1;
try {
Runtime runtime = Runtime.getRuntime();
Process process = runtime.exec(new String[] {Line3});
process.waitFor();
BufferedReader Lecteur = new BufferedReader(new InputStreamReader(process.getInputStream()));
BufferedReader Erreur = new BufferedReader(new InputStreamReader(process.getErrorStream()));
BufferedWriter Ecriture = new BufferedWriter(new OutputStreamReader(process.getOutputStream()));
}
catch(IOException ioe){
while((Line2 = Erreur.readLine()) != null){
Line2=Erreur.readLine();
System.out.println(Line2);}
ioe.printStackTrace();process.destroy();
}
catch(InterruptedException e){
System.out.println("Application interrompu par le System");
e.printStackTrace();
process.destroy();
}
finally {}
}
public void run(){
System.out.println("La commande est lancée et L'execution de la commande se fait attendre");
System.out.println("La valeur de sortie de l'executione est:"+process.exitValue());
Lecteur.close();
Ecriture.close();
Erreur.close();
threade1.stop();
}
}
public class Partie1{
public String valeur = null;
BufferedReader Entre;
threadE1 threade1;
public static void main(String args[]){
System.out.println("Le programmme attend les commandes Systeme ?Executer");
System.out.println("Prennez soin de mettre des Double cotes et des sur une seule ligne :Merci");
try{
while(true){
Entre = new BufferedReader(new ImputStreamReader(System.in));
valeur=Entre.readLine();
if(valeur!=null){
threade1 = new threadE1(valeur);
threade1.start();}
}
}
catch(IOException ioe) {
System.out.println("Erreur d'Entrée Sortie s'est Produite");
ioe.printStackTrace();
}
finally{
}
}
}
Et un peu d'exemple pourra par exemple sur l'utilisation de votre blog est voici:import shell.ProcessConsumer;
import shell.Shell;
import java.io.*;
import java.lang.Object;
public class Utilisation{
public static void main(String[] args){
String resultat;
shell sh=new Shell();
sh.shell();//au lieu de sh.command("la commnde");
ProcessConsumer ps= new ProcessConsumer(sh);
resultat1=ps.input( new FileInputStream(System.in));//"in.txt"));//par default le clavier
resultat2=ps.output( new FileOutputStream("out.txt")); //par defaut Ecran
resultat3=pserror( new FileOutputStream("err.txt")); //par defaut Ecran
ps.consume();
System.out.println("La version du shell est :"+sh.toString());
System.out.println("La situation de passage des variable d'Environnement :"+sh.isSystemEnvInherited());
System.outprintln("Le chartSet par default est :" +sh.getCharset());
System.out.println("Le repertoire de Lancemant de la commande est::"+sh.getDirectory());
System.out.println(" resultat de sortie à afficher:"+resultat2);
(essayer apres de boucler sur un programme qui boucle en esxecutant des commandes shell comme dans le premier programme)
}
}
APRES Compilation ses erreurs au sein meme de votre packetages sont generée donc je peux meme pas continuer:
/*./shell/ProcessConsumer.java:484: illegal start of expression
Future inputTask = null;
^
./shell/ProcessConsumer.java:484: not a statement
Future inputTask = null;
^
./shell/ProcessConsumer.java:485: illegal start of expression
Future errorTask = null;
^
./shell/ProcessConsumer.java:485: not a statement
Future errorTask = null;
^
./shell/ProcessConsumer.java:553: expected
public Future consumeInBackground() {
Si tou allais bien j'avais voulu lui adapter la même phiolosophie bouclante d'introduction de commande à partir du clavier.
Merci de vouloir bien m'aider à resoudre le problème.
04/04/2007 @ 15:59 Je vais peut-être faire une version compatible 1.4 voir moins mais cela aura un impact sur les fonctionnalités...
Quand à ton problème, il vaux mieux utiliser le forum IO car le blog n'est pas vraiment fait pour cela (et le code n'est pas très lisible).
a++
04/04/2007 @ 16:17 Mais avec des gestions d'évenements pour savoir où en été les processus.
Bref, aujourd'hui, nous passons à UIMA (
http://incubator.apache.org/uima/ )
Pour la gestion des programmes externes, et du coup ton API me semble plus légère et plus conviviale que la mienne ( bravo! ).
Donc, on va regarder ça au labo, et si ça tourne mieux que mon API, on te tient au courant si on corrige des bugs ou rajoute des développements autour! Peut être le début d'une collaboration..
16/11/2007 @ 11:36 J'ai continué à ajouter quelques petites modifications (comme la détection du charset de la console Dos sous Windows, ou l'utilisation du shell utilisateur), et il faudrait que je fasse une doc un peu plus complète, mais dès que je peux je poste tout cela ici ;)
a++
16/11/2007 @ 14:47 j'ai 2 questions sur ton api :
1er : comment faire pour paralléliser l'execution de command line (j'ai vu l' executor service et le partir Future inBackground mais je "donne ma langue au chat" ...)
N.B : j'appel une appli graphique avec un shell1 et un processconsumer1 spécfique puis une appli en ligne de commande avec son propre shell2 et son processconsumer2 mais celle-ci attend la fin de l'appli graphique ??)
2eme : comment faire pour "killer" un shell dont on aurait un identifiant (et lequel ?)
Merci d'avance pour tes réponses !! :)
et ton api est vraiment sympa !!
11/12/2007 @ 08:24 1. Il suffit d'utiliser consumeInBackground() pour que les traitements soient exécutées dans une tâche de fond, par exemple :
Shell shell = new Shell();
Future cmd1 = shell.system("cmd1").consumeInBackground();
Future cmd2 = shell.system("cmd2").consumeInBackground();2. Il n'y a pas vraiment de processus Shell, mais un processus par commande exécutée. Si tu l'as lancé en tâche de fond tu peux utiliser la méthode cancel(true) de l'objet Future pour arrêter le process...
a++
11/12/2007 @ 09:40 dans un 1er temps, merci pour ta réponse !
J'utilisais ta solution en partie ... je m'explique :
je faisais pour la cmd1 un consumeInBackground avec Futur
puis pour la cmd2 un comsumeAsString avec un String
donc la cmd2 était bloquée par la cmd1
Donc conclusion : tout est maintenant en consumeInBackground
a+
11/12/2007 @ 12:23 En effet, je veux pouvoir lancer une appli en jar sur un serveur à partir d'un autre appli java...et je souhaite récupérer le flux de sortie du programme appellé.
Je lance donc tout en shell via ssh :
ssh root@dimsrvli -n "cd /var/www/appli/ && java -jar Insee.jar"
Ca fonctionne très bien avec ta classe Shell...
Seulement je souhaiterez récupérer ma sortie dans une boucle pour pouvoir intégrer les retours à mon API Logging...
En gros, réussir à brancher la sortie out et la sortie err sur un Reader, que je pourrais lire via readline().
Je me doute qu'il faut utiliser les flux pour cela, mais après de nombreux essais infructueux...je me suis dis que tu pourrais peut être m'aider...
Merci d'avance!
09/01/2008 @ 12:13 Je te confirme que l'on est entrain d'utiliser ton API dans notre labo de bioInfo. En effet, pour gérer nos programmes, cela fonctionne très bien. On a déjà relevé un petit bug. :-) En fait plutôt une fonctionnalité manquante.
Dans les paramètres à donner aux programmes on a souvent des "|" qui ne sont pas des pipes. Si on utilise ton API en les entourant d'apostrophe, pas de problème, mais si on le "backslash", ( ce qui fonctionne dans une console ), cela ne fonctionne pas via ton API. Je pense qu'il y aura le même problème si il y a un '>' ou un '
07/02/2008 @ 10:29 En fait tu as plusieurs solution comme implémenté ton propre Appendable, mais le plus simple est surement d'utiliser les PipedReader/PipedWriter :
String command = ...
Shell sh = new Shell();
PipedReader reader = new PipedReader();
// On prépare la commande
sh.command(command)
// En lui associant un PipedWriter sur sa sortie
.output(new PipedWriter(reader))
// Et en l'exécutant dans une tâche de fond :
.consumeInBackground();
// Puis on lit les données depuis le PipeReader :
BufferedReader br = new BufferedReader(reader);
try {
String line;
while ( (line=br.readLine()) != null ) {
System.out.println(" ==> " + line);
}
} finally {
br.close();
}
Je suppose que tu tournes sous Linux/Unix car la protection par slash ne fonctionne pas sur la console DOS... mais je n'ai pas de machine où je peux tester cela pour le moment.
a++
12/02/2008 @ 10:51 Exemple pour traiter: bon|boulot|adiguba, il faudra taper: "bon\\|boulot\\|adiguba"
Et cela fonctionne très bien. Bien sûr, mettre entre cote reste le moyen privilégié.
13/02/2008 @ 10:08 Merci pour cette api qui facilite beaucoup de choses. J'utilise justement un programme qui passe par le terminal habituellement dans un projet. Il s'agit de curl. J'ai besoin de lancer 2 instances de curl en parallèle pour récupérer des flux audio et vidéo depuis un serveur. J'y arrive très bien avec cette API en passant par consumeInBackground(), qui retourne des Future donc.
Justement, j'ai aussi besoin de récupérer la sortie des erreurs de curl pour que mon programme sache s'il y a eu un problème ou non. Curieusement, je n'ai pas réussi. Les messages s'affichent bien dans la console (sous Eclipse), mais lorsque je tente de mettre le résultat dans un String, je n'ai rien! Pourriez-vous m'indiquer une manière de faire dans ce genre de cas ?
Merci d'avance, et bravo pour cet outil très utile.
08/07/2008 @ 03:00 Ceci devrait faire l'affaire :
StringBuilder out = new StringBuilder();
StringBuilder err = new StringBuilder();
Future process = sh.command("curl ...")
.output(out).error(err)
.consumeInBackground();
Non ?
a++
08/07/2008 @ 09:13 Je me posais justement la question de l'utilisation de .output(PrintStream) et de .error(...), ayant bien compris que la solution était là. Je ne suis pas encore assez coutumier de Java visiblement, puisque je n'avais pas pensé à écrire ça comme ça.
Merci beaucoup pour cette réponse claire, rapide, et efficace!!
09/07/2008 @ 02:41 J'essayer d'executer des commandes interactive linux comme vi ou top
Mais j'ai toujours le même problème, avec ou sans ta lib.
avec top j'ai ce retour:
"top: failed tty get"
et si j'essayai d'executer vi il s'execute bizarement , la gestion du clavier ne fonctionne pas et il ya des warning au lancement:
Vim: Warning: Output is not to a terminal
Vim: Warning: Input is not from a terminal
Si tu as une idée?
apparemment il faudrait faire un truc avec tty ...
17/09/2008 @ 17:43 C'est donc tout à fait normal que cela ne fonctionne pas...
Si tu veux les lancer depuis ton programme, il faut passer par un vrai terminal, comme par exemple xterm :
xterm -e via++
18/09/2008 @ 09:25 Tout d'abord, bravo pour cet article des plus intéressant.
J'ai toutefois une question :
J'aimerais lancer un programme externe (un autre jar), mais que l'appelant se finisse, une fois que l'autre jar est lancé (et ainsi libérer les ressources, car jusqu'à présent, le premier reste dans les processus, ce qui est logique).
Existe-t-il une solution ?
26/01/2009 @ 12:49 Je tiens à préciser que j'aimerais éviter "l'astuce" du type :
xterm -e "java -jar progB.jar"A l'heure actuelle, la solution la plus "viable" est que je génère en dynamique un launcher (launcher.bat pour windobe et launcher.sh pour linux) avec la commande :
java -jar progB.jar (qui a l'avantage de libérer les ressources, du moins sous linux) qui me donne un assez bon résultat, mais ne me satisfait pas pleinement, d'où ma précédente question.
28/01/2009 @ 12:02 Un exemple pour rediriger les sorties dans un JTextField ?
Il faut passer par ProcessConsumer j'imagine, mais quel process est en paramètre ?
Sinon, est-il possible de régler l'encodage ?
La sortie pour un ping par exemple est :
Envoi d'une requˆte 'ping' sur www.l.google.com [74.125.43.105] avec 32 octets de donn‚esÿ:
R‚ponse de 74.125.43.105ÿ: octets=32 temps=65 ms TTL=49
R‚ponse de 74.125.43.105ÿ: octets=32 temps=66 ms TTL=49
R‚ponse de 74.125.43.105ÿ: octets=32 temps=65 ms TTL=49
R‚ponse de 74.125.43.105ÿ: octets=32 temps=66 ms TTL=49
Statistiques Ping pour 74.125.43.105:
Paquetsÿ: envoy‚s = 4, re‡us = 4, perdus = 0 (perte 0%),
Dur‚e approximative des boucles en millisecondes :
Minimum = 65ms, Maximum = 66ms, Moyenne = 65ms
Les caractères accentués sont perdus.
Merci
10/08/2009 @ 11:36 Le problème est que l'encodage par défaut est windows-1252, et que les applications console utilisent le cp850. Du coup les données ne sont pas lu dans le bon encodage et on se retrouve des trucs bizarres sur les accents...
Il faut donc forcer l'utilisation de cet encodage pour la lecture des flux du process :
Shell shell = new Shell();
shell.setCharset("cp850");
shell.command("ping www.google.com").consume();Mais attention car c'est spécifique à Windows !
Sinon pour la redirection vers un JTextField, je pense que tu voulais plutôt parler de rediriger vers un JTextPane ou un JTextArea, non ?
Il ne faut pas passer par ProcessConsumer qui ne devrait être utilisé QUE pour gérer des process qui ne serait pas lancé par la classe Shell.
En fait il suffit d'implémenter ton propre objet "Appendable", qui recevra les données lu et les ajoutera au composant textuelle. Par exemple :
public class AppendableJTextComponent implements Appendable {
private final JTextComponent component;
public AppendableJTextComponent(JTextComponent comp) {
this.component = comp;
}
@Override
public Appendable append(char c) throws IOException {
appendStringOnEDT(Character.toString(c));
return this;
}
@Override
public Appendable append(CharSequence csq, int start, int end)
throws IOException {
appendStringOnEDT(csq.subSequence(start, end).toString());
return this;
}
@Override
public Appendable append(CharSequence csq) throws IOException {
appendStringOnEDT(csq.toString());
return this;
}
private void appendStringOnEDT(final String str) {
if (SwingUtilities.isEventDispatchThread()) {
Document doc = component.getDocument();
if (doc != null) {
try {
doc.insertString(doc.getLength(), str, null);
} catch (BadLocationException e) {
throw new RuntimeException(e);
}
}
} else {
SwingUtilities.invokeLater(new Runnable() {
@Override
public void run() {
appendStringOnEDT(str);
}
});
}
}
}
Ensuite il suffit d'utiliser cet appendable comme output :
final JTextPane textpane = new JTextPane();
JButton button = new JButton("ping");
button.addActionListener(new ActionListener() {
@Override
public void actionPerformed(ActionEvent e) {
new SwingWorker() {
@Override
protected Integer doInBackground() throws Exception {
Shell shell = new Shell();
shell.setCharset("cp850");
return shell.command("ping www.google.com").output(new AppendableJTextComponent(textpane)).consume();
}
}.execute();
}
});
JFrame frame = new JFrame("Demo");
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
frame.setSize(400,400);
frame.setLocationRelativeTo(null);
frame.getContentPane().add(new JScrollPane(textpane));
frame.getContentPane().add(button, BorderLayout.SOUTH);
frame.setVisible(true);
a++
10/08/2009 @ 12:13 J'avais trouvé une solution avec un JTextField en redirigeant System.out dedans, mais ça ne le mettait pas à jour en temps réel, j'aime beaucoup ta solution "Appendable".
Pour le charset, je n'avais essayé que UTF-8 et ISO Latin, merci pour l'astuce !
10/08/2009 @ 15:41 En ce qui concerne les redirections (que ce soit avec le ProcessBuilder ou avec API) : est-ce que le principe reste valable si la commande qu'on invoque correspond à un programme Java utilisant java.io.Console (et pas System.out) ? J'ai plutôt l'impression que non
06/11/2009 @ 11:38 a++
06/11/2009 @ 16:42 Merci beaucoup pour cette API
Laurent
28/03/2010 @ 23:59 je te felécite pour ton API!Mais j'ai eu un petie defficulté!!
ben,je veux bien lance des commande en tant que root! alors j'essaye la chose suivant:
package Shell;
import com.developpez.adiguba.shell.Shell;
import java.io.*;
public class TestCmd {
public static void test() throws IOException{
Shell sh = new Shell();
String result = sh.command("sudo snort -c /etc/snort/snort.conf").consumeAsString();
System.out.print(result);
}
public static void main(String[] args) throws IOException{
TestCmd.test();
}
}
Mais il m'affiche l'errur suivant:
sudo: no tty present and no askpass program specified
Svp tu as une idée comment le reglé?
Merci une autre fois!
07/04/2010 @ 22:53 a++
08/04/2010 @ 09:06 Merci pour ton API !!
J'aurais une petite question, enfin plutôt un problème.
J'ai utilisé ton API, pour mon programme, une fois terminé je fais un jar de mon programme, et là quand je lance mon jar, j'obtiens l'erreur suivante :
Exception in thread "main" java.lang.NoClassDefFoundError: com/developpez/adigub
a/shell/Shell
Saurais tu d'où ça viens ?
Merci
20/04/2010 @ 16:09 Donc en gros il ne trouve pas la librairie. Vérifie bien ton classpath selon la manière dont tu lances ton application.
a++
21/04/2010 @ 09:05 a++
21/04/2010 @ 10:02 String[] command = { "cmd.exe", "/C", "Start", ShellFile.getAbsolutePath() };
Shell sh = new Shell(); sh.exec(command).consume();
Mais au final, j'aimerais que la commande soit l'execution d'un fichier .sh (jusque là ça va) et où dans ce fichier, il y ait des commandes ainsi que des lancements de fichiers perl.
Cela ne pose pas de problème ? Au niveau de l'ordonnancement ?
En tout cas très belle API ;-)
27/04/2010 @ 11:02
27/07/2010 @ 15:43 Vous devez être identifié pour poster un commentaire.
Liste des blogs
adiGuba:Blog
Ce blog est mis à disposition sous un contrat Creative Commons BY-NC-SA.
Mes tutoriels
- Présentation de Java SE 6
- Les Annotations de Java 5.0
- La JSTL (Java Standard Tag Library)
- Les Expressions Languages (EL)
- Les JSP Taglibs
Petite sélection de discussion des forums "Java"
- Classes, méthodes private
- Difference de performances Unix/Windows d'un programme?
- Recuperation du nom des parametres
- Possibilité d'accéder au type générique en runtime
- Définition exacte de @Override
- [ fuite ] memoire
- L'apparition du mot-clé const est-il prévu dans une version à venir du JDK?
- [REFLEXION] Connaitre toutes les classes qui implémentent une interface
System.gc()a encore frappé : jre 1.5, tomcat 6.0 et multi processeurs
Liens
Tutoriels Java SE
Tutoriels Java EE
Sélection du blog
Java SE/EE et Web en général
Catégories
Rechercher
| Lun | Mar | Mer | Jeu | Ven | Sam | Dim |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | |||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 |
| 26 | 27 | 28 | 29 | 30 | 31 |
Divers
Syndiquez ce blog 
Articles :
Commentaires :
![[Valid RSS]](/img/valid-rss.png "Validate my RSS feed")
![[Valid Atom 1.0]](/img/valid-atom.png "Validate my Atom 1.0 feed")
Copyright © 2000-2012 - www.developpez.com