Java et commande système

Version imprimable

19/12/2006, 10h25
F2S

Java et commande système

Bonjour à tous,

Mon soucis est que je voudrai lancer des commandes systèmes ou des scripts shell à partir de mon code java.
J'ai bien qqs idées, mais rien de tres claire...

donc si qqn aurait une idée "lunimeuse" pour éclairé, je lui en serais reconnaissant

Merci d'avance
19/12/2006, 10h27
thibaut

Code:

Runtime.getRuntime().exec("<commande>");
19/12/2006, 10h31
F2S

Merci pour la rapidité...

je pensais bien qu'il fallait utilisé "java.lang.Runtime", mais je ne me pensais pas que c'était aussi simple...

je vais tester merci
19/12/2006, 11h22
F2S

Cool hé bien ça fonctionne bien, par contre une petite chose à dire pour ce qui tomberaient sur cette discussion.

si vous voulez executer un fichier ".bat", il faut mettre le chemin complet avec deux "\" au lieu d'un.
exemple : D:\\tmp\\test.bat

et pour les fichier shell et compagnie, je pense que la syntaxe devrait être :
"D:/tmp/test.sh" ( à vérifier )
19/12/2006, 11h34
F2S

que de précision.

Les bonnes pratiques pour exécuter une application externe.
19/12/2006, 12h18
F2S

Comment faire pour récupérer le resultat de la commande ?
19/12/2006, 12h24
thibaut
Quand tu fait Runtime.getRuntime.exec(); tu récupère un objet de type Process.

Et tu dois faire :
Code:

1 2 Process process = Runtime.getRuntime.exec(); InputStream in = process.getInputStream();
Et lire sur le flux InputStream...
14/02/2007, 18h25
diamonds

Citation:

Envoyé par thibaut

Code:

Runtime.getRuntime().exec("<commande>");

Bonjour

Moi j'ai une application web (Java avec Netbeans + VWP).
Au click d'un bouton sur ma page web, je veux qu'un fichier shell soit lançé.

Ce fichier shell se trouve sur un serveur de fichier Unix qui est accessible par le réseau local.

Comment alors la commande Runtime.getRuntime().exec("<commande>") saurait que moi je parle de ce serveur de fichier unix ?

Merci.
14/02/2007, 20h32
iohack

Citation:

Envoyé par diamonds

Bonjour

Moi j'ai une application web (Java avec Netbeans + VWP).
Au click d'un bouton sur ma page web, je veux qu'un fichier shell soit lançé.

Ce fichier shell se trouve sur un serveur de fichier Unix qui est accessible par le réseau local.

Comment alors la commande Runtime.getRuntime().exec("<commande>") saurait que moi je parle de ce serveur de fichier unix ?

Merci.

Runtime.getRuntime().exec("rsh [paramètres] commande") ;
14/02/2007, 20h54
diamonds

Citation:

Envoyé par iohack

Runtime.getRuntime().exec("rsh [paramètres] commande") ;

à quelle place ? dans l'évenement OnClick du bouton à cliquer ?
14/02/2007, 21h04
*alexandre*

J espere que command n'est pas un paramètre de ta page web, executé des commandes systèmes depuis une page web n est vraiment pas secure

prévois bien la définition de rôle pour chacun des users
15/02/2007, 00h58
diamonds

Citation:

Envoyé par *alexandre*

J espere que command n'est pas un paramètre de ta page web, executé des commandes systèmes depuis une page web n est vraiment pas secure

Les utilisateurs n'ont pas accès à l'internet. C'est juste des employés interne qui vont le faire sur l'intranet.

Qu'est ce que tu veux dire par

Citation:

prévois bien la définition de rôle pour chacun des users
15/02/2007, 01h18
diamonds
Citation:

Envoyé par iohack

Runtime.getRuntime().exec("rsh [paramètres] commande") ;

Si par exemple je veux lancer sur la ligne de commande de unix la commande suivante :
Code:

1 2 >ls -l
est ce que les instructions java seront :

Code:

Runtime.getRuntime().exec("rsh -l ls") ;

ou bien comme Thibaut a dit :
Code:

1 2 3 4 Runtime.getRuntime().exec("<commande>"); Runtime.getRuntime().exec("ls -l");
Est-ce que ça prend une classe ou une bibliothèque qu'il faut importer ?
15/02/2007, 09h35
STB_Fk

Bonjour,

Normalement pas d'import a réaliser pour utiliser ces fonctions.

Par :

Citation:

prévois bien la définition de rôle pour chacun des user

Il veut dire que si n'importe quel utilisateur peut executer une commande qui est passé en parametre d'une page web, c'est super dangeraux surtout dans un milieu professionel. Ex : un rm * lancé sur ton serveur ne sera pas vraiment du plus belle effet. C'est pour cela que tu dois autoriser les commandes qu'a des utilisateurs de confiances si elles sont passé en paramètres. Mais vaut mieux éviter de donner de telles possibilités aux users.

Fk
15/02/2007, 12h16
diamonds

Citation:

Envoyé par STB_Fk

Bonjour,

Normalement pas d'import a réaliser pour utiliser ces fonctions.

Par :

Il veut dire que si n'importe quel utilisateur peut executer une commande qui est passé en parametre d'une page web, c'est super dangeraux surtout dans un milieu professionel. Ex : un rm * lancé sur ton serveur ne sera pas vraiment du plus belle effet. C'est pour cela que tu dois autoriser les commandes qu'a des utilisateurs de confiances si elles sont passé en paramètres. Mais vaut mieux éviter de donner de telles possibilités aux users.

Fk

Mais je présume que ce type de sécurité est déjà fait au niveau du système unix.

java ne peut pas (je pense) modifier ces permissions pour qu'un user puisse les utiliser de manière frauduleuse.
Est-ce que je me trompe ?
15/02/2007, 15h43
STB_Fk

Je pense que si!
Quel utilisateur utilise tu pour executer ta commande unix??
Si tu peux gérer des droits directement avec Java c'est pas plus mal.
Après tout dépend de la confiance que tu as dans les users

Fk
15/02/2007, 16h01
_Mac_

Citation:

Envoyé par diamonds

Ce fichier shell se trouve sur un serveur de fichier Unix qui est accessible par le réseau local.

Comment alors la commande Runtime.getRuntime().exec("<commande>") saurait que moi je parle de ce serveur de fichier unix ?

Décris-nous ton archi : d'un côté tu as l'utilisateur devant son PC qui parle avec un serveur J2EE. On est en train de voir comment ce serveur J2EE peut exécuter des commandes Shell. On est bien d'accord ?

Citation:

Envoyé par diamonds

java ne peut pas (je pense) modifier ces permissions pour qu'un user puisse les utiliser de manière frauduleuse.
Est-ce que je me trompe ?

La commande qui sera appelée par le serveur J2EE avec Runtime.getRuntime().exec("<commande>") quelque soit <commande>, que ce soit un rsh, un ls ou autre chose, sera exécuté sur le serveur en tant qu'utilisateur qui fait tourner le serveur J2EE. Par exemple, si ton serveur J2EE est un Tomcat et qu'il a été démarré avec l'utilisateur système apache, c'est l'utilisateur apache qui invoquera la commande.

Du coup, il faut t'assurer de plusieurs choses :
- Qui (i.e. quel utilisateur système) doit exécuter le script shell ? Il y a éventuellement une problématique de mot de passe/connexion authentifiée à gérer. Voir les 2 points suivants. Dans tous les cas, il faut éviter au maximum d'avoir à manipuler un mot de passe, pour des problèmes de sécurité mais aussi pour des raisons de simplicité : si le mot de passe change, c'est pas mal si on peut éviter d'avoir à reconfigurer l'appli.
- Si le script shell a exécuté se trouve sur le serveur J2EE, l'utilisateur apache peut-il correctement exécuter la commande (pour tester, il faut se connecter sur le serveur avec l'utilisateur apache et exécuter la commande). Si c'est un autre utilisateur qu'apache qui doit exécuter le script, faut installer et utiliser une "passerelle" du type sudo qui t'éviteras d'avoir à stocker et synchroniser un mot de passe.
- Si le script shell se trouve sur une autre machine, il faut effectivement utiliser rsh pour l'invoquer. Avec rsh, il est possible de passer un utilisateur différent, et ce qui est bien, c'est qu'une fois bien configuré, tu n'as plus besoin de passer de mot de passe. Mais il faut bien le configurer (par défaut, faut un mot de passe).

Dans tous les cas, il faut se poser la question de la sécurité : faire en sorte que seules les personnes habilitées peuvent invoquer la commande shell. Ca, ça se fait plutôt par ton application Web. Eviter par exemple de faire passer la commande à exécuter dans l'URL. Ca vaut même pour une application interne.

Bon courage.
15/02/2007, 16h31
diamonds

Citation:

Envoyé par _Mac_

Décris-nous ton archi : d'un côté tu as l'utilisateur devant son PC qui parle avec un serveur J2EE. On est en train de voir comment ce serveur J2EE peut exécuter des commandes Shell. On est bien d'accord ?

La commande qui sera appelée par le serveur J2EE avec Runtime.getRuntime().exec("<commande>") quelque soit <commande>, que ce soit un rsh, un ls ou autre chose, sera exécuté sur le serveur en tant qu'utilisateur qui fait tourner le serveur J2EE. Par exemple, si ton serveur J2EE est un Tomcat et qu'il a été démarré avec l'utilisateur système apache, c'est l'utilisateur apache qui invoquera la commande.

Du coup, il faut t'assurer de plusieurs choses :
- Qui (i.e. quel utilisateur système) doit exécuter le script shell ? Il y a éventuellement une problématique de mot de passe/connexion authentifiée à gérer. Voir les 2 points suivants. Dans tous les cas, il faut éviter au maximum d'avoir à manipuler un mot de passe, pour des problèmes de sécurité mais aussi pour des raisons de simplicité : si le mot de passe change, c'est pas mal si on peut éviter d'avoir à reconfigurer l'appli.
- Si le script shell a exécuté se trouve sur le serveur J2EE, l'utilisateur apache peut-il correctement exécuter la commande (pour tester, il faut se connecter sur le serveur avec l'utilisateur apache et exécuter la commande). Si c'est un autre utilisateur qu'apache qui doit exécuter le script, faut installer et utiliser une "passerelle" du type sudo qui t'éviteras d'avoir à stocker et synchroniser un mot de passe.
- Si le script shell se trouve sur une autre machine, il faut effectivement utiliser rsh pour l'invoquer. Avec rsh, il est possible de passer un utilisateur différent, et ce qui est bien, c'est qu'une fois bien configuré, tu n'as plus besoin de passer de mot de passe. Mais il faut bien le configurer (par défaut, faut un mot de passe).

Dans tous les cas, il faut se poser la question de la sécurité : faire en sorte que seules les personnes habilitées peuvent invoquer la commande shell. Ca, ça se fait plutôt par ton application Web. Eviter par exemple de faire passer la commande à exécuter dans l'URL. Ca vaut même pour une application interne.

Bon courage.

Salut mac

à la lecture de ton message, j'ai eu beaucoup d'autres idées.

voici l'architecture :

L'utilisateur lance l'application sur son pc à partir d'un lien (dans l'intranet)
Le serveur appelons le A

A est un serveur de fichier unix (solaris) qui contient aussi un serveur web apache et un serveur web tomcat.

A contient aussi le script shell que je veux éxécuter

A contiendra aussi les fichiers qui seront crées à l'exécution du script shell.

Maintenant moi je veux que au lancement de cette application web, lorsque l'utilisateur click sur un bouton, le script sur la machine A soit lançé.

Oui la machine A est accessible par un userid et un mot de passe.

Je veux que ce script peut être lançé à partir de l'application web et je me suis dit qu'il faut biensur mettre un userid et un mot de passe dans l'application java capable de lancer ce script mais sans plus.

mais lorsque je déploi l'application, le code source de l'application ne va pas être visible normalement étant donné qu'on donne jsute le .war (ou les .jar). Est-ce que c'est vrai ?

Le code source de l'application sera la possession de l'administrateur du système seulement.

Qu'est ce que t'en pense ? ya t-il d'autres choses auxquels je dois faire atention ?

dans ce cas, faut-il utiliser rsh ou non ?

Je ne comprends pas ce passage dans les utilisateurs

Citation:

Par exemple, si ton serveur J2EE est un Tomcat et qu'il a été démarré avec l'utilisateur système apache, c'est l'utilisateur apache qui invoquera la commande.
15/02/2007, 16h59
_Mac_

Citation:

Envoyé par diamonds

Oui la machine A est accessible par un userid et un mot de passe.

Je veux que ce script peut être lançé à partir de l'application web et je me suis dit qu'il faut biensur mettre un userid et un mot de passe dans l'application java capable de lancer ce script mais sans plus.

[...]

Je ne comprends pas ce passage dans les utilisateurs

Pour le moment, oublie le userid/password : tu nous dis que le script est sur la même machine que Tomcat, donc y a peut-être moyen de ne pas s'occuper de ça.

Sur un serveur, quelque soit l'OS, les programmes fonctionnent avec un certain utilisateur : l'utilisateur qui a démarré le programme. Quand on démarre Tomcat, on se connecte bien sur la machine avec un utilisateur (je prenais l'exemple de l'utilisateur "apache") et on tappe la commande de démarrage de Tomcat. C'est cet utilisateur qui fait tourner Tomcat. La JVM de Tomcat tourne donc sur le serveur en tant que cet utilisateur (apache dans mon exemple). Donc tout ce que fait Tomcat et ton programme se fait sur le serveur en tant qu'apache, y compris le lancement de ton script shell avec Runtime.exec(). Pour que ton truc marche, il faut donc s'assurer que l'utilisateur apache peut exécuter ce script shell et que script fonctionnera alors correctement.

Au passage, si l'utilisateur que vous utilisez réellement pour lancer Tomcat est root (à la place de apache), c'est pas top du tout du tout du tout. Pourquoi ? Parce que ton script sera appelé en tant que root, donc en tant que super utilisateur et donc potentiellement il peut tout faire, y compris des bêtises. C'est d'autant plus dangereux si le chemin du script à exécuter apparaît qq part dans les URL. Dans ce cas, pour déconner, un gars peut appeler la commande rm ou je ne sais quoi d'autre et là, c'est la merde. C'est pour ça qu'il faut super bien protéger ton appli et faire en sorte que le nom du script n'apparaisse nulle part.

Citation:

Envoyé par diamonds

mais lorsque je déploi l'application, le code source de l'application ne va pas être visible normalement étant donné qu'on donne jsute le .war (ou les .jar). Est-ce que c'est vrai ?

Oui, c'est juste, mais ça ne change rien au problème. Tu ne livres pas le script dans ton war, si ? Dans ce cas, je ne suis pas sûr que tu puisses faire fonctionner ton script car il manquera vraisemblablement le flag x (exécutable) sur ton script.

Du coup, le mieux je pense est de livrer ton appli Tomcat dans un war et de livré ton script shell à part. Dans ta procédure de livraison, tu dis bien évidemment d'installer le war dans Tomcat et de copier le shell dans un certain répertoire du serveur. Il faut que ce répertoire soit un paramètre de ton application Tomcat de manière à pouvoir le paramétrer sans avoir à modifier le code de ton appli. Il te suffit alors de récupérer ce répertoire dans ton appli et de l'utiliser dans ton Runtime.exec() pour construire le chemin complet vers ton script. A la limite, ton paramètre est ce chemin complet (/rep1/rep2/script.sh) comme ça, y a pas de pb si le nom du script change.

Citation:

Envoyé par diamonds

Le code source de l'application sera la possession de l'administrateur du système seulement.

Si tu veux...

Citation:

Envoyé par diamonds

dans ce cas, faut-il utiliser rsh ou non ?

Non dans la mesure où le script se trouve sur la même machine que le serveur Tomcat. rsh c'est uniquement dans le cas où le script se trouve sur une autre machine que le serveur Tomcat.
15/02/2007, 19h58
diamonds

Citation:

Pour que ton truc marche, il faut donc s'assurer que l'utilisateur apache peut exécuter ce script shell et que ce script fonctionnera alors correctement.

Comment puis-je vérifier si l'utilisateur apache peut exécuter ce script ? est-ce l'essayer avec un classique http://..... ?

Citation:

Au passage, si l'utilisateur que vous utilisez réellement pour lancer Tomcat est root (à la place de apache), c'est pas top du tout du tout du tout. Pourquoi ? Parce que ton script sera appelé en tant que root, donc en tant que super utilisateur et donc potentiellement il peut tout faire, y compris des bêtises.

Comment l'administrateur du système peut vérifier si c'est le root qui lance Tomcat ou si c'est un autre utilisateur ?

Citation:

C'est d'autant plus dangereux si le chemin du script à exécuter apparaît qq part dans les URL. Dans ce cas, pour déconner, un gars peut appeler la commande rm ou je ne sais quoi d'autre et là, c'est la merde. C'est pour ça qu'il faut super bien protéger ton appli et faire en sorte que le nom du script n'apparaisse nulle part.

Non, le chemin du script ne dois pas apparaitre dans les URL, parcontre il va se trouver quelque part dans le code source de l'application. en l'occurence la ligne

Code:

Runtime.getRuntime().exec...

Citation:

Oui, c'est juste, mais ça ne change rien au problème. Tu ne livres pas le script dans ton war, si ? Dans ce cas, je ne suis pas sûr que tu puisses faire fonctionner ton script car il manquera vraisemblablement le flag x (exécutable) sur ton script.

Je ne comprends pas ce que tu veux dire par le flag x. ce script je lui donnerais les droits d'exécution suivants : x pour le owner, pour le groupe, et aussi pour les autres. Alors tout le monde aura le droit d'éxécuter ce script, mais s'ils veulent déconner, ils doivent d'abord passer par un userid et un mot de passe pour ouvrir la connexion avec le serveur. Ce userid et ce mot de passe vont se trouver quelques part dans le code source. à moins que après la connexion, pour une raison ou une autre, l'application se break au milieu, et l'utilisateur se retrouvera directement devant la ligne de commande de ce serveur.

Citation:

Il faut que ce répertoire soit un paramètre de ton application Tomcat de manière à pouvoir le paramétrer sans avoir à modifier le code de ton appli. Il te suffit alors de récupérer ce répertoire dans ton appli et de l'utiliser dans ton Runtime.exec() pour construire le chemin complet vers ton script. A la limite, ton paramètre est ce chemin complet (/rep1/rep2/script.sh) comme ça, y a pas de pb si le nom du script change.

Pas sur de bien comprendre ici.
Supposons que mon .war se trouve sur

Code:

/machin/webapps/monapplication.war

et le script shell se trouve sur

Code:

/rep1/rep2/script.sh

Est-ce que la ligne java qui va lancer le script sera de la forme suivante ?

Code:

Runtime.getRuntime().exec("/rep1/rep2/script.sh");

si oui, si un jour le nom du script change ou bien si son emplacement change, on va devoir faire des modifications dans cette ligne :

Code:

Runtime.getRuntime().exec("/rep1/rep2/script.sh");

pour moi : parametre = "/rep1/rep2/script.sh" est-ce exact ?
il y a quelque chose que j'échappe.

Diamonds
16/02/2007, 10h13
Anubis

Bonjour,

J'ai aussi un problème avec la classe runtime.

En fait je veux faire un cvs checkout a partir d'un programme java mais cela ne marche pas, cela ne me crée pas les fichier relatif au checkout.

ma commande est du type :
r.exec("cvs -d /home/Ref/ checkout -d /home/moi/Desktop/workspace monmodule");

Est ce que vous avez une idée d'où vient le problème?

Merci.
16/02/2007, 10h32
_Mac_

Citation:

Envoyé par diamonds

Comment puis-je vérifier si l'utilisateur apache peut exécuter ce script ? est-ce l'essayer avec un classique http://..... ?

Tu lis mes messages ??? Cf. le premier que j'ai posté :

Citation:

Envoyé par _Mac_

pour tester, il faut se connecter sur le serveur avec l'utilisateur apache et exécuter la commande

Citation:

Envoyé par diamonds

Comment l'administrateur du système peut vérifier si c'est le root qui lance Tomcat ou si c'est un autre utilisateur ?

C'est son boulot de savoir ce genre de chose. Comment fait-il pour lancer Tomcat ? Avec quel utilisateur lance-t-il la commande ? Sinon, pour le savoir, faut faire un "ps -ef | grep java" et là t'as toutes les commandes java qui tourne sur le système qui s'affichent. L'utilisateur apparaît en début de ligne.

Citation:

Envoyé par diamonds

Non, le chemin du script ne dois pas apparaitre dans les URL, parcontre il va se trouver quelque part dans le code source de l'application. en l'occurence la ligne

Code:

Runtime.getRuntime().exec...

Ca me paraît normal, mais pour des raisons de flexibilité, je pense que c'est préférable de mettre au moins le répertoire où se trouve le script dans un paramètre de l'application : si ce répertoire doit changer pour une raison inconnue, c'est du simple paramétrage, t'as pas à recompiler l'appli.

Citation:

Envoyé par diamonds

Je ne comprends pas ce que tu veux dire par le flag x. ce script je lui donnerais les droits d'exécution suivants : x pour le owner, pour le groupe, et aussi pour les autres.

Pourquoi pas. Je voulais juste dire que si tu mets le script dans ton WAR, il ne sera pas exécutable (pas de flag x pour personne).

Citation:

Envoyé par diamonds

Ce userid et ce mot de passe vont se trouver quelques part dans le code source.

Ca, je comprends pas : t'en n'as pas besoin dans l'appli du mot de passe si tu sais que c'est le même utilisateur système que Tomcat qui doit appeler ce script... Et même si tu dois changer d'utilisateur, je pense que c'est mieux de passer par un truc du style sudo pour appeler la commande car ça t'évitera d'avoir à écrire un mot de passe en clair quelque part.

Citation:

Envoyé par diamonds

Pas sur de bien comprendre ici.
Supposons que mon .war se trouve sur

Code:

/machin/webapps/monapplication.war

et le script shell se trouve sur

Code:

/rep1/rep2/script.sh

Est-ce que la ligne java qui va lancer le script sera de la forme suivante ?

Code:

Runtime.getRuntime().exec("/rep1/rep2/script.sh");

si oui, si un jour le nom du script change ou bien si son emplacement change, on va devoir faire des modifications dans cette ligne :

Code:

Runtime.getRuntime().exec("/rep1/rep2/script.sh");

pour moi : parametre = "/rep1/rep2/script.sh" est-ce exact ?
il y a quelque chose que j'échappe.

Diamonds

Si, c'est tout à fait ça. Ton paramètre vaut bien "/rep1/rep2/script.sh". Ton appli récupère ce paramètre et le passe Runtime.getRuntime().exec(). Mais qu'on se comprenne bien : quand je parle de paramètre, je ne parle pas d'une simple variable dans ton code Java : c'est soit une valeur qui se trouve dans un fichier de config genre properties, soit une entrée d'environnement ou un init param de ton servlet (les 2 derniers sont préférables car modifiables post déploiement directement depuis la console d'admin).
16/02/2007, 10h34
_Mac_

Citation:

Envoyé par Anubis

Est ce que vous avez une idée d'où vient le problème?

T'as un message d'erreur ? Parce que comme ça, pas trop d'idée. La seule qui me vient à l'esprit c'est qu'il est possible qu'il ne trouve pas la commande cvs parce qu'elle ne se trouve pas dans son path. T'as essayé en mettant le chemin complet vers la commande cvs ? Genre :

Code:

r.exec("/usr/bin/cvs -d /home/Ref/ checkout -d /home/moi/Desktop/workspace monmodule");
16/02/2007, 10h40
Anubis

avec /usr/bin/cvs cela ne amrche pas mieux.
Mais c'est vrai je n'ai regardé que le flux normal et pas celui d'erreur je test ça et je vous dis.

edit: en fait j'ai trouvé.
Dans le flux de sorti d'erreur il me dit qu'il n'arrive pas a parser la date que je founi pour mon checkout.
merci de ton aide.
16/02/2007, 10h49
_Mac_

Citation:

Envoyé par Anubis

Mais c'est vrai je n'ai regardé que le flux normal et pas celui d'erreur je test ça et je vous dis.

:king: Sans commentaire...
16/02/2007, 11h08
Anubis

heu là je ne comprend pas:
je construit ma commande dans une chaine de caractère comme elle devrait être dans un terminal. je la fais afficher je la copie, je la met dans un terminal elle marche impec.

Je la lance avec runtime il me répond Can't parse date/time: `"2004-07-13'

Est ce que java code les caractères " d'un façon particulière qui n'est pas reconnu par le terminal?

edit: J'ai trouvé la solution, vous la voulez? :p

Bon en fait j'ai découpé ma commande en un tableau et je l'ai passé à exec et apparement cela marche.

Citation:
Envoyé par thibaut
Quand tu fait Runtime.getRuntime.exec(); tu récupère un objet de type Process.

Et tu dois faire :
Code:

1 2 Process process = Runtime.getRuntime.exec(); InputStream in = process.getInputStream();
Et lire sur le flux InputStream...
Comment lire cette donnée sur le inputstream

mettons que j'ai un textarea sur ma page et je veux lui affecter la sortie de la commande "dir" comme suit :
Code:

1 2 3 4 5 Runtime runtime = Runtime.getRuntime(); Process process = Runtime.getRuntime().exec(new String[] { "dir" , "C:\\" } ); InputStream in = process.getInputStream(); textArea1.setValue = in....
Merci.

26/02/2007, 18h07
le y@m's

Voici un tutoriel sur le package j ava.io (package destiné à la manipulation des flux) qui devrais t'aider ;).
26/02/2007, 19h09
diamonds

Citation:

Envoyé par Anubis

heu là je ne comprend pas:
je construit ma commande dans une chaine de caractère comme elle devrait être dans un terminal. je la fais afficher je la copie, je la met dans un terminal elle marche impec.

Je la lance avec runtime il me répond Can't parse date/time: `"2004-07-13'

Est ce que java code les caractères " d'un façon particulière qui n'est pas reconnu par le terminal?

edit: J'ai trouvé la solution, vous la voulez? :p

Bon en fait j'ai découpé ma commande en un tableau et je l'ai passé à exec et apparement cela marche.

Comment tu as fais pour lire le flux inputstream ?

Ca, je comprends pas : t'en n'as pas besoin dans l'appli du mot de passe si tu sais que c'est le même utilisateur système que Tomcat qui doit appeler ce script... Et même si tu dois changer d'utilisateur, je pense que c'est mieux de passer par un truc du style sudo pour appeler la commande car ça t'évitera d'avoir à écrire un mot de passe en clair quelque part.

Bon d´accord. Regardons ceci :

je veux exécuter un script qui contient la commande "ls" pour afficher.

sur ma page web je fais ceci dans le code d'un bouton
Code:

1 2 3 4 5 6 7 8 9 10 public String button1_action() throws IOException { Runtime runtime = Runtime.getRuntime(); Process process = Runtime.getRuntime().exec(new String[] { "/XXX/ls" , "/home" } ); InputStream in = process.getInputStream(); // textArea1.setValue = in.getClass().; return null; }
J'ai mettons 3 serveur unix (A, B, C)

Sans utiliser un login et un mot de passe, comment puis-je dire que je veux lancer le script qui se trouve sur le serveur B et non pas A ou C?

Le répertoire /home et /XXX se trouve effectivement tous les deux sur la machine B

Le hic c'est que maintenant je fais encore le développement sur mon pc personnel. Alors il me semble que je dois me loguer au serveur unix (en l'occurence B) d'une manière ou d'une autre.

Une fois le développement sera fini, je metterais à ce moment là le .war sur le serveur unix B (et peut-être dans ce cas, je n'aurais pas besoin de me loguer)

Peux tu détailler un peu sur le trux "sudo"

Merci.

Bonjour,

Je me permet d'utiliser ce sujet pour mon problème qui reste dans le sujet ^^

Mon appli tourne sous Windows et je souhaite que l'execution de mon programme execute un 2em programme dans une nouvelle console.
Mon problème se trouve dans l'ouverture de cette nouvelle console.

en gros pour le moment voici la partie qui pose problème :
Code:

1 2 Runtime runtime = Runtime.getRuntime(); Process process = runtime.exec("java -cp ./;lib/soap.jar;lib/mail.jar;lib/activation.jar;lib/xerces.jar AffichageChat " + pseudo);
Je souhaite donc executer (2em ligne) mon programme GetSentence MAIS dans une autre console.

Si quelqu'un a une idée de comment faire :D

EDIT : J'ai réglé mon problème :
Code:

1 2 Runtime runtime = Runtime.getRuntime(); Process process = runtime.exec(new String[] { "cmd.exe", "/C", "start java -cp ./;lib/soap.jar;lib/mail.jar;lib/activation.jar;lib/xerces.jar AffichageChat " + pseudo});