Forum Programmation.java Ouvrir l'éditeur par défaut dans une console

Posté par  (site web personnel) .
Étiquettes : aucune
0
1
juin
2010

Bonjour,



Je voudrais dans une application console (donc non graphique) ouvrir l'éditeur par défaut afin d'éditer un fichier.



J'essaie avec la classe Desktop mais elle ne semble pas supportée dans une console (elle a sans doute besoin d'une Frame). Le code suivant ne fonctionne donc pas 





if (Desktop.isDesktopSupported()) {


            try {


                File tempFile = File.createTempFile("recette", null);


                Desktop.getDesktop().edit(tempFile);





            } catch (IOException ex) {


                


            }


J'essaie alors (et ce sera moins portable) avec la classe Runtime. Un code du style fonctionne; 





try {


            File tempFile = File.createTempFile("recette", null);


            //tempFile.deleteOnExit();


            Process p = Runtime.getRuntime().exec("/usr/bin/gvim "


                    + tempFile.getName());


            p.waitFor();


} ...


... mais lorsque je change gvim en vim, ça ne fonctionne plus. Et ce que je veux faire c'es éditer le code dans la console qui lance l'application (ce qui veulent savoir pourquoi c'est parce que l'application sera accessible via SHH).



Des idées ?

  • # ça ne t'aidera pas beaucoup, mais..

    Posté par  . Évalué à 3.

    La Javadoc dit sur les objets Process :

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

    Il faudrait trouver un moyen de conserver le terminal du processus java, et je ne sais pas si c'est possible ou non.

  • # UNE console ou LA console

    Posté par  . Évalué à 2.

    dans un premier cas, tu peux peut-etre ouvrir une console supplementaire pour afficher tes infos et ton programme.

    dans le deuxieme, il va falloir jouer des flux pour les gerer...

    3e question, tu dois vraiment le faire en java en ligne de commande ?

    • [^] # Re: UNE console ou LA console

      Posté par  (site web personnel) . Évalué à 1.

      Je veux bien dire UNE, je voudrais lancer mon programme dans une console et que ce programme lance un éditeur dans cette même console :-)

      Oui c'est en Java en ligne de commande, le prof (moi) veut ça ;-)

  • # $EDITOR

    Posté par  . Évalué à 2.

    D’t’façon, c’est ni vim ni gvim, c’est $VISUAL, $EDITOR, $ALTERNATE_EDITOR, ou encore /usr/bin/editor qu’il faut utiliser.

    Et comme dit plus haut, il faut parfois le lancer dans sa propre console : cas des éditeurs en console qui n’aiment pas (et on les comprend) ne pas avoir accès au terminal ; Process ne donnant que des flux, ils ne peuvent plus utiliser les fonctionnalités du terminal (déplacements notamment).
    (En C, un fork(2) puis un execlp(2) du shell fonctionne bien (donc $SHELL -c $VISUAL), ça permet d’avoir les bonnes variables, de gérer les alias de l’utilisateur… Dommage que Process soit trop malin…)

    Tu peux aussi prévoir une option pour lancer une console autour de l’éditeur si besoin (x-terminal-emulator sur les systèmes avec des « alternatives », sinon prévoir aussi une option pour le nom de celui-ci).

    C’est le problème dès qu’on veut laisser le choix aux utilisateurs : trop de possibilités, tout le monde ne suit pas le standard…

    • [^] # Re: $EDITOR

      Posté par  (site web personnel) . Évalué à 1.

      Merci pour la réponse mais tu n'es pas du tout clair pour moi ...

      • [^] # Re: $EDITOR

        Posté par  . Évalué à 1.

        Alors je vais essayer de la refaire :o)

        1. Si Desktop n’est pas utilisable, il y a des variables d’environnement ($VISUAL, $EDITOR $ALTERNATE_EDITOR) qui permettent de connaître l’éditeur préféré de l’utilisateur. Il existe aussi parfois (systèmes à base Debian au moins) le lien symbolique /usr/bin/editor. (Sinon on aurait pu glisser sur des réflexions comme « mets Emacs, ça marche ».)
        Bon, il faut encore que les utilisateurs renseignent ces variables…

        2. Un éditeur en console utilise les capacités de la console (le terminal), ne serait-ce que les déplacements du curseur. La classe Process ne fournit au processus appelé que des flux (des fichiers, System.in/out/err), donc cela empêche parfois le processus d’avoir accès à toutes les capacités du terminal. gvim est dans sa propre fenêtre, donc ça ne lui pose pas de problème. vim veut utiliser la console mais les flux qu’on lui donne ne lui suffisent pas.
        En C, on fait un fork() et un exec() et le processus fils récupère directement les flux du père et peut donc utiliser la console sans soucis. Runtime.exec() ressemble plus à un popen() : le processus fils récupère des flux, mais ce ne sont pas les mêmes que celui du père (ce sont des tubes), donc ils ne sont pas directement liés à la console, donc exit l’interactivité (c’est comme si tu lançais "cat | editor" en console (quoique parfois ça fonctionne…)).

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.