[Runtime] Rediriger la sortie d'un processus

**GLDavid** · 15/08/2005, 21h15

Bonjour

En parcourant avec la fonction Rechercher, je me suis appuyé sur l'un des codes proposé. Mon objectif est de pouvoir afficher sur la sortie standard le résultat d'une commande Unix lancé à partir d'un code Java.
Voici mon code :

Code :

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

1
2
3
4
5
6
7
8
9
10
 
try {
            Process process = Runtime.getRuntime().exec("ls /boot/config*");
            BufferedReader ds = new BufferedReader(new InputStreamReader(process.getInputStream()));
            String lineCourante = ds.readLine();
            while (lineCourante != null) {
                System.out.println(lineCourante);
                lineCourante = ds.readLine();
            }
        }

La commande en mode shell fonctionne. Par contre, à l'exécution, rien ne s'affiche !
Donc, où est mon erreur ?

Merci d'avance de vos réponses.

@++

**KiLVaiDeN** · 15/08/2005, 21h31

The Runtime.exec methods may not work well for special processes on certain native platforms, such as native windowing processes, daemon processes, Win16/DOS processes on Microsoft Windows, or shell scripts. The created subprocess does not have its own terminal or console. All its standard io (i.e. stdin, stdout, stderr) operations will be redirected to the parent process through three streams (Process.getOutputStream(), Process.getInputStream(), Process.getErrorStream()). The parent process uses these streams to feed input to and get output from the subprocess. Because some native platforms only provide limited buffer size for standard input and output streams, failure to promptly write the input stream or read the output stream of the subprocess may cause the subprocess to block, and even deadlock.

Ca voudrait dire que dans ton cas, le stream n'est peut-être pas renseigné..

Si tel est le cas, et qu'aucune parade n'a été trouvée ( je viens de vérifier sur la doc 1.5.0 et c'est toujours la même chose ) il ne te reste plus qu'à faire un système de redirection de l'output de tes scripts shell vers un fichier de log.. Puis dans ton programme Java d'interroger ce dernier lorsque le process a fini.. Pas génial

Peut-être quelqu'un a une idée ?

**parsy** · 15/08/2005, 21h47

Ton code semble correct

J'ai moi-même eu des ennuis avec ce type de programme où je ne n'ai pas pu récupérer le résultat de certaines commandes unix mais avecls ça marche à coup sûr.

J'ai trouvé ce lien

http://www.mountainstorm.com/publications/javazine.html

qui fait la même chose

son code est

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
import	java.io.*;
 
class execInput {
    public static void main(String Argv[]) {
        try {
            String ls_str;
            Process ls_proc = Runtime.getRuntime().exec("/bin/ls -aFl");
	    // get its output (your input) stream
            DataInputStream ls_in = new DataInputStream(
                      ls_proc.getInputStream())  ;
            try {
                while ((ls_str = ls_in.readLine()) != null) {
                    System.out.println(ls_str);
	        }
            } catch (IOException e) {
                System.exit(0);
            }
        } catch (IOException e1) {
            System.err.println(e1);
            System.exit(1);
        }
        System.exit(0);
    }
}

A première vue la seule différence est l'utilisation de DataInputStream à la place de BufferedInputStream mais je ne pense pas que ce soit l'erreur surtout que tu transformes bien ton flux d'octets en flux de caractères avec InputStreamReader

En espérant t'avoir aidé

Sinon essaye avec un ls tout seul

**KiLVaiDeN** · 15/08/2005, 22h02

Travailles-tu en multi-threads ?

**GLDavid** · 15/08/2005, 23h02

Bonsoir

Merci de vos réponses, je vais tâcher de répondre à vos questions.
parsy, j'ai essayé ce code :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
try {
            Process process = Runtime.getRuntime().exec("ls /boot/config*");
            DataInputStream ls_in = new DataInputStream(process.getInputStream());
            String ls_str;
            while ((ls_str = ls_in.readLine()) != null) {
                System.out.println(ls_str);
            }
        } catch (IOException ioe){
            JOptionPane.showMessageDialog(null, "Erreur pour renommer le fichier de configuration !", "Erreur", JOptionPane.ERROR_MESSAGE);
            System.exit(7);
        }

Hélas, le résultat est le même, rien ne s'affiche.
KiLVaiDeN : non, je ne travaille pas en multi-thread. Y a t'il une importance ?
Sinon, j'ai bien peur de devoir faire ce que KiLVaiDeN me recommande mais je trouve cette solution bizarre, voir complètement alambiqué.
Merci encore de votre aide.

@++

**KiLVaiDeN** · 15/08/2005, 23h32

Je viens de voir quelque chose. En fait il vaudrait peut-être mieux séparer la commande, de ses arguments, donc l'idée de Parsy ( de tester uniquement avec un ls tout simple ) était pertinente.

Pour séparer la commande de ses arguments, il faut utiliser un tableau de String :

Code :

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

1
2
Process 	exec(String[] cmdarray)
          Executes the specified command and arguments in a separate process.

Sinon je vois pas, je parlais des threads car j'ai eu l'impression que ça pouvait poser un problème de lire le flux de retour d'un processus à partir d'un thread, ça ne doit poser aucun problème, mais dans ma tête ça fait un petit blocage

**KiLVaiDeN** · 15/08/2005, 23h40

Un lien rempli d'exemples qui pourraient être utiles !

Bonne nuit je suis HS

**herve91** · 15/08/2005, 23h41

Le caractère joker '*' est interprétable par le shell (sh ou autre), et non par la comande ls. Plutôt que

Process process = Runtime.getRuntime().exec("ls /boot/config*");

il faudrait faire :

Code :

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

1
2
String[] cmdarray = {"/bin/sh", "-c", "ls", "/boot/config*"};
Process process = Runtime.getRuntime().exec(cmdarray);

**GLDavid** · 16/08/2005, 10h41

Ok, je vais essayer aujourd'hui, je vous tiens au courant.
Merci de votre aide !

@++

**GLDavid** · 16/08/2005, 11h09

Salut

herve91, j'ai testé ton code avec celui-ci :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
try {
            String[]cmd = {"/bin/sh", "-c", "ls", "/boot/config*"};
            Process process = Runtime.getRuntime().exec(cmd);
            BufferedReader ds = new BufferedReader(new InputStreamReader(process.getInputStream()));
            String lineCourante = ds.readLine();
            while (lineCourante != null) {
                System.out.println(lineCourante);
                lineCourante = ds.readLine();
            } 
        } catch (IOException ioe){
            JOptionPane.showMessageDialog(null, "Erreur pour renommer le fichier de configuration !", "Erreur", JOptionPane.ERROR_MESSAGE);
            System.exit(7);
        }

Là, j'ai un résultat qui s'affiche :

Code :

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

1
2
3
4
5
6
7
8
 
build
build.xml
dist
manifest.mf
nbproject
src
test

Et oui, ça me liste les fichiers...mais du répertoire de mon projet

Mais bon, un peu de courage, je pense que je touche au but.
Merci de votre aide.

@++

**herve91** · 16/08/2005, 11h20

Oups, oui, je viens de voir l'erreur...

Code :

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

String[]cmd = {"/bin/sh", "-c", "ls /boot/config*"};

Ca devrait aller mieux comme ça...

**GLDavid** · 16/08/2005, 11h27

Nickel chrome !

Un grand merci à toi herve91 ainsi qu'à KiLVaiDeN et parsy

Ca marche impeccable !

A charge de revanche !

@++

**KiLVaiDeN** · 16/08/2005, 12h07

Deux questions que je me pose quand même :

Le fait de passer par le shell pour lancer ls, est-ce obligatoire, ou seulement parce qu'il voulait utiliser le joker ? Parce que je suis un peu gêné par le fait que ça implique d'instancier sh, ça serait plus optimisé d'appeller directement ls non ? Et d'ailleurs, quand on appelle sh de cette façon, est-ce que ça crée un processus sh, qui lui même crée un processus ls ?

La méthode exec peut aussi prendre un paramètre envp, qui est un String[]. A quoi correspond ce paramètre ? Je n'ai jamais vu d'exemple à ce sujet, dans la docs ils parlent de variables d'environnement, mais je ne comprend pas bien l'utilisation qu'on puisse en avoir, bien que je sache ce qu'est une variable d'environnement..

Est-ce que ça aurait marché si dans la configuration initiale, la commande avait été un "ls" tout simple ? As-tu testé ?

Merci de m'eclairer

**herve91** · 16/08/2005, 12h25

Envoyé par KiLVaiDeN

Le fait de passer par le shell pour lancer ls, est-ce obligatoire, ou seulement parce qu'il voulait utiliser le joker ? Parce que je suis un peu gêné par le fait que ça implique d'instancier sh, ça serait plus optimisé d'appeller directement ls non ? Et d'ailleurs, quand on appelle sh de cette façon, est-ce que ça crée un processus sh, qui lui même crée un processus ls ?

Effectivement, c'est uniquement parce qu'il voulait utiliser le joker, qui est interprétable seulement par le shell. Oui aussi pour la seconde question, c'est plus optimisé en lançant directement ls (ça évite de créer un processus intermédiaire). Et enfin, oui pour la troisième question, il y a deux processus créés, le processus père "sh" attendant la fin du processus fils "ls".

Envoyé par KiLVaiDeN

La méthode exec peut aussi prendre un paramètre envp, qui est un String[]. A quoi correspond ce paramètre ? Je n'ai jamais vu d'exemple à ce sujet, dans la docs ils parlent de variables d'environnement, mais je ne comprend pas bien l'utilisation qu'on puisse en avoir, bien que je sache ce qu'est une variable d'environnement.

envp est un tableau de chaînes de caractères donnant la liste des variables d'environnement avec leur valeur. Chaque chaîne est de la forme

Code :

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

variable=valeur

par exemple

Code :

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

HOME=/home/users/toto

Si tu ne précises pas "envp" au niveau du exec, c'est l'environnement du processus courant qui est passé. Tu peux avoir besoin de passer des informations au processus fils via les variables d'environnement, dans ce cas tu construis un "envp" en rapport.

Envoyé par KiLVaiDeN

Est-ce que ça aurait marché si dans la configuration initiale, la commande avait été un "ls" tout simple ? As-tu testé ?

Elle aurait marchait, oui