Discussion :

[chezwam56]

Bonjour a tous!

Alors voila mon problème :

Je veux faire une ptite appli qui s'occupe de régler l'heure du PC quand celui démarre (la pile ma carte mère a un peu de mal et l'heure se dérègle assez souvent...)

Seulement voila, je n'arrive pas à exécuter le .bat qui devrait normalement se charger de faire ça...

Je vous file la classe qui marche pas pour ceux qui veulent tester :

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
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
 
import java.io.File;
import java.io.FileWriter;
import java.io.PrintWriter;
 
public class DateHeure {
 
    public static void main(String args[]) {
        new DateHeure();
    }
 
    public DateHeure() {
        setTime("12:00", "03-03-09");
    }
 
    private void setTime(String heure, String date) {
        try {
            if (new File("date.bat").exists()) {
                new File("date.bat").delete();
            }
 
            new File("date.bat").createNewFile();
 
            PrintWriter pw = new PrintWriter(new FileWriter("date.bat"));
            pw.println("date " + date);
            pw.println("time " + heure);
            pw.close();
 
            Runtime r = Runtime.getRuntime();
            //  !!!!! REMPLACER LE PATH VERS LE .BAT POUR TESTER !!!!!
            r.exec("cmd /c C:/PROG/DateHeure/date.bat");
 
            // déjà essayé :
            // r.exec("cmd /c \"cmd /c C:/PROG/DateHeure/date.bat\"");
            // r.exec("C:/PROG/DateHeure/date.bat");
 
        } catch (Exception ex) {
            ex.printStackTrace();
        }
    }
}

Le .bat est bien créé (ou mis a jour) à chaque exécution...

Quand je le lance dans une invite MS-DOS, ca marche.
Quand je lance la commande "cmd /c C:/PROG/DateHeure/date.bat" dans le 'Démarrer>Exécuter' de windows, ça marche.

Mais quand j'essaye d'exécuter tout ça depuis java... ca passe pas...

Quelqu'un a une idée???
Merci d'avance

[herch]

salut,

et si tu essayais avec

Code :

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

1
2
3
4
 
Runtime r = Runtime.getRuntime();
String[] cmdAExecuter = {"cmd.exe", "/c", "C:\\PROG\\DateHeure\\date.bat"};
r.exec(cmdAExecuter);

il y a plein de post sur ce forum portant sur ce sujet; tu pourrais faire une petite recherche

[Uther]

Je dirais même plus:

Code :

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

1
2
3
4
5
Runtime r = Runtime.getRuntime();
String[] cmdAExecuter = {"cmd.exe", "/c", "C:\\PROG\\DateHeure\\date.bat"};
r.exec(cmdAExecuter);
r.getInputStream().close();
r.getErrorStream().close();

[chezwam56]

Bonsoir a tous!

Tout d'abord, merci de s'être penché sur le problème

MAIS... parce qu'il y a un mais!
Déjà, juste pour dire que j'avais fait quelques recherches sur le forum pour trouver comment exécuter un .bat ... mais je pense que vous n'avez pas testé la classe que j'ai posté, car le Java n'arrive pas a modifier l'heure système en exécutant le .bat généré...

Et je comprend pas pourquoiiiiiiiiiiiiiiii!!!!
En double cliquant sur le .bat, ça change l'heure, en le lançant depuis le prog java, rien ne se passe... (Pas d'erreurs, RIEN!)

Alors, est ce un problème de droits ou un truc comme ca? Java n'a t il pas le droit de toucher aux propriétés du système (ça m'étonnerais mais bon, je sèche la!)

Que les sceptiques exécutent la ptite classe que j'ai posté pour comprendre ce que je veux dire (En changeant le path vers le .bat bien sur!)

A++

[herch]

en effet, ça donne pas le résultat

j'ai essayé en récupérant la sortie, et ça a marché... pourquoi?? aucune idée

Code :

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

1
2
3
4
5
6
7
8
 
Runtime r = Runtime.getRuntime();
Process p = r.exec(new String[]{"cmd", "/c", "date.bat"});
BufferedReader reader = new BufferedReader(new InputStreamReader(p.getInputStream()));
String ligne;
while((ligne = reader.readLine()) != null)
	System.out.println(ligne);
reader.close();

[Uther]

C'est normal, les flux de sortie et d'erreur pouvant être bloquant suivant le type d'application, il faut soit les consommer, soit les fermer. Ce problème est lui aussi évoqué au moins quelques dizaines de fois.

Par contre avec seulement un close() sur la sortie comme je l'avais suggéré, ça ne marche pas? Je veux pas tester ça car je ne suis pas sous windows, mais il me semble bien que normalement c'est suffisant.

[herch]

salut,

je viens de tester en faisant seulement la fermeture des flux comme indiqué, mais ça n'a pas l'air de marcher

par contre dans l'exemple que j'avais donné, c'était pas la peine d'afficher la ligne récupéré, apparemment il faut seulement boucler sur le flux récupéré

Code :

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

1
2
 
while(reader.readLine() != null);

au lieu de

Code :

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

1
2
3
4
 
String ligne;
while((ligne = reader.readLine()) != null)
	System.out.println(ligne);

pour le pourquoi ...

[adiGuba]

Salut,

je viens de tester en faisant seulement la fermeture des flux comme indiqué, mais ça n'a pas l'air de marcher

On pourrait voir le code complet...

Il faut traiter/fermer tous les flux ! Et savoir ceux qui sont utilisé par les programmes appelées...

par contre dans l'exemple que j'avais donné, c'était pas la peine d'afficher la ligne récupéré, apparemment il faut seulement boucler sur le flux récupéré

Code :

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

1
2
 
while(reader.readLine() != null);

Quel intérêt y-a-t-il à lire le flux dans ce cas ?
Au passage il serait utile de lire et afficher les flux de sortie... au moins pour détecter une éventuelle erreur...

Sinon comme d'habitude pour ce type de problème, les lectures obligatoires :

• Tutoriel : Exécuter une application externe en Java
• Blog : Runtime.exec() n'est pas des plus simple...

a++

[herch]

je crois qu'il y a un malentendu, c'est pas mon post

mais bon, puisqu'on est tous là pour apprendre, j'avais testé en fermant les flux comme l'avait propoé Uther

Code :

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

1
2
3
4
5
6
 
Runtime r = Runtime.getRuntime();
Process p = r.exec(new String[]{"cmd", "/c", "date.bat"});
p.getInputStream().close();
p.getOutputStream().close();
p.getErrorStream().close();

le reste du code, c'est le même que celui en hauuuut de la page. Mais ça ne marchait pas. la date restait inchangé

Quel intérêt y-a-t-il à lire le flux dans ce cas ?

aucune idée, c'est juste que j'avais testé cela juste pour voir, et il s'est avéré que le code du fichier bat s'exécutait dans ce cas

Sinon comme d'habitude pour ce type de problème, les lectures obligatoires :

* Tutoriel : Exécuter une application externe en Java
* Blog : Runtime.exec() n'est pas des plus simple...

oui, je sais, on les rencontre souvent dans le forum.

[adiGuba]

je crois qu'il y a un malentendu, c'est pas mon post

Oups en effet

mais bon, puisqu'on est tous là pour apprendre, j'avais testé en fermant les flux comme l'avait propoé Uther

Le problème en fermant tout c'est qu'on ne peut pas voir les éventuelles erreur généré par le programme appelé...

oui, je sais, on les rencontre souvent dans le forum.

oui, je sais

a++

[herch]

peut être que la réponse réside ici

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).

à ma grande honte, même si ces 2 liens se répètent souvent, je ne les avais jamais lus attentivement.

donc, peut être que la réponse à cette question

Quel intérêt y-a-t-il à lire le flux dans ce cas ?

est expliqué en haut. enfin, je pense ...

[adiGuba]

Si tu fermes le flux ce problème de blocage n'apparait plus (le processus ecrira dans le vide), mais tu perds les éventuelles messages d'erreur...

a++

[herch]

c'est tout à fait logique, mais dans ce cas , et contre toute logique, ça veut pas marcher

il y a un fichier un fichier "date.bat" qui contient disons les 2 lignes suivantes

Code :

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

1
2
3
 
date 12-12-02
time 12:00

normalement ça devrait marcher en faisant

Code :

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

Runtime.getRuntime().exec(new String[]{"cmd", "\c", "date.bat"});

et en fermant après les flux, mais ça marche pas.

mais bon, merci pour tes remarques, et aussi pour l'article dans le blog

[adiGuba]

Déjà attention car c'est /C et non pas \C qu'il faut utiliser


Sinon je viens de faire quelques essais et en effet le batch est interrompu si on ferme le flux de sortie...

Mais ce doit être une une particularité des batchs Windows qui plante si leurs flux de sortie est coupé (d'ailleurs le code de retour est 1). Je viens de tester en appelant un programme directement, puis en le mettant dans un batch et cette seconde solution foire si on ferme les flux !

Lorsqu'on utilise une commande externe, on est fortement dépendant de son comportement, et en cas de problème il est impératif de lire les flux de sortie et le code retour pour en détecter l'origine...



Donc ici on est obligé de lire le flux de sortie, mais je ne comprend toujours pas pourquoi le fait de passer à une bouche while "vide" a résolu le problème dans ton précédent post

a++

[herch]

salut,

oui, c'est "/c".. une erreur de frappe.

la boucle while marchait dans le cas où elle est vide et dans le cas où on écrit la ligne récupéré.

peut être que le problème vient du fait qu'on lance un batch qui lui aussi lance d'autres commande, et donc... peut être... d'autres process fils, et en fermant les flux, on tue ces process, mais en lisant le flux, on donne du temps à ces process de s'exécuter... mais bon, je dis ça comme, et à vrai dire, j'y comprends rien moi aussi

[adiGuba]

la boucle while marchait dans le cas où elle est vide et dans le cas où on écrit la ligne récupéré.

Ok j'avais compris que cela ne fonctionnait pas dans le second cas... ce que je trouvais étrange

a++

[herch]

je viens de trouver enfin ce qui va pas

il fallait tout simplement faire process.waitFor pour donner le temps à la commande pour s'exécuter.
donc, pas de boucle while

Code :

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

1
2
3
4
5
6
7
 
Runtime r = Runtime.getRuntime();
Process p = r.exec(new String[]{"cmd", "/c", "date.bat"});
p.waitFor();
p.getInputStream().close();
p.getOutputStream().close();
p.getErrorStream().close();

C'est tout bête, mais bon...

et le propriétaire du post, il est où

[adiGuba]

C'est tout bête, mais bon...

Non non ce code n'est pas bon !!!

Dans le cas présent il est obligatoire de traiter les flux de sorties (en parallèle depuis 2 threads différents). On ne peut pas les fermer car sinon la commande "cmd" arrêtera le traitement du batch.

Ici cela marche par "chance" car le batch n'écrit rien dans sa sortie standard (et les buffers restent vide), mais rajoute un ligne comme ceci :

Code batch :

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

dir c:\windows c:\windows\system32

Cela va écrire beaucoup de données dans les flux de sorties, ce qui va bloquer les buffers :

• Le batch va être bloqué en écriture, en attendant que le programme java lise les buffers
• Le programme java va être bloqué sur le waitFor(), c'est à dire qu'il attendra la fin du batch

Le traitement des flux DOIT toujours avoir lieu AVANT le waitFor() (ou en parallèle).


Perso j'utilise le format suivant pour être sûr de mon coup :

Code :

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

1
2
3
4
5
6
7
8
	Process p = ...
	try {
		// Traitement des flux (en parallèle)
		p.waitFor();
	} finally {
		// On détruit le process (au cas où)
		p.destroy();
	}

et le propriétaire du post, il est où

Heu... c'est pas toi

a++

[herch]

Heu... c'est pas toi

non... je suis propriétaire par intérim

en effet, j'ai testé avec la ligne

Code :

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

dir c:\windows c:\windows\system32

et ça bloquait

donc, la morale de tout cela

Les flux vous lirez
Les flux vous fermerez
A adiGuba, vos questions vos poserez

mais après lecture des flux, est-ce obligatoire de faire appel à waitFor()??

Dans le cas présent il est obligatoire de traiter les flux de sorties (en parallèle depuis 2 threads différents). On ne peut pas les fermer car sinon la commande "cmd" arrêtera le traitement du batch.

j'ai pas compris la partie des 2 threads

[adiGuba]

mais après lecture des flux, est-ce obligatoire de faire appel à waitFor()??

Non... mais cela permet de s'assurer que le processus est bien terminé (si on veut récupérer son code de retour ou effectuer un traitement après son exécution).

j'ai pas compris la partie des 2 threads

3 si on traite le flux d'entré !

Le process peut effectuer 3 opérations basiques sur ses entrée/sorties :

• Lire dans son entré standard.
• Ecrire dans sa sortie standard.
• Ecrire dans sa sortie d'erreur.

On sait que si le process écrit "plein" de donnée dans une de ses sorties, et que le programme Java ne lit pas le buffer correspondant, il va se retrouver bloquer sur une opération d'écriture jusqu'à ce que les données soit lu.


Si tu fait ceci en séquentiel, alors les buffers seront vidé un après l'autre :

Code :

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

1
2
3
4
5
6
7
Process p = ...
 
InputStream in = p.getInputStream();
// Lecture du flux de sortie standard
 
InputStream err = p.getErrorStream();
// Lecture du flux d'erreur

Or tu ne sortiras de la boucle de lecture que lorsque tu recevra le signal de fin de flux, c'est à dire lorsque le process sera terminé (à moins qu'il ne ferme prématurément son flux de par lui-même).

Cas problématique : Ton process génère une erreur, et écrit un message bien long dans sa sortie d'erreur (une méchante stacktrace par exemple ).

Il remplit le buffer associé au flux d'erreur et se retrouve bloqué en écriture, jusqu'à ce que le buffer soit lu. Or pendant ce temps là le programme Java est bloqué en attente de lecture sur le flux de sortie standard du process...

Encore une fois les deux process s'attendent mutuellement...


Comme les opérations de lecture sont bloquantes et que tu ne peux pas savoir quel flux recevra des données, il faut les traiter en parallèle !



On a le même problème pour le flux d'entrée : si le process tente de lire le flux d'entré et que le programme java n'écrit pas dedans on se retrouvera bloqué


Dans tous les cas si on ne les utilises pas, il est préférable de fermer les flux : cela permet au moins au process de générer une erreur et de se terminer (c'est toujours mieux que de rester bloqué indéfiniment).

a++