Définition de l’environnement pour System.in

Je conçois une application console pour un serveur exécutant RedHat. Les utilisateurs finaux doivent pouvoir exécuter cette application avec n’importe quel terminal de leur choix. (Par exemple, Terminal Gnome, Putty SSH / Telnet, Client MS Telnet et autres).

Dans la plupart des applications de terminal, il n’y a rien de mal, mais lorsque je lance mon programme à partir d’une session MS telnet, je remarque que mes entrées spéciales pour System.in et System.console() sont totalement endommagées. Un retour arrière écrit ^H sur l’écran et les autres touches écrivent également du charabia.

Je l’ai suffisamment piraté pour que je puisse le faire fonctionner de manière cohérente, mais je suis sûr que ce que je fais est grossier:

 if (!System.getenv("TERM").equals("xterm")) { System.out.println("\nWARNING: The TERM type is now set to xterm\n"); final Ssortingng[] cmd = { "/bin/sh", "-c", "export TERM=xterm" }; Runtime.getRuntime().exec(cmd); }

Y aurait-il un problème ici pour les terminaux qui ne supportent pas xterm ? Je remarque que le client Microsoft Telnet ne vous permet pas de définir le type TERM sur xterm avant de commencer une session. Une fois la session démarrée, cependant, définir TERM=xterm semble résoudre le problème.

Comment la plupart des applications de console abordent-elles ce problème?

Avec les applications de terminal de caractères, la communication comporte toujours deux objectives, qui doivent convenir à la manière d’interpréter les caractères de contrôle. Généralement, les deux côtés sont capables d’utiliser une variété de codages décrits dans la firebase database termcap / terminfo .

Sur le côté serveur d’Unix, vous pouvez définir le codage en définissant la variable d’environnement TERM ou en utilisant stty (une valeur par défaut est utilisée autrement, souvent une émulation de terminal bête).

Du côté du client, vous devez également définir la même émulation de terminal que du côté serveur. Telnet natif de Windows a la capacité de définir l’émulation (voir par exemple Configurer le type de terminal Telnet ), tout comme d’autres émulateurs de terminal (par exemple, Putty).

Concernant vos décisions en matière de conception : Les parameters de terminal ci-dessus ne sont généralement décrits que dans la documentation utilisateur, et ne sont pas codés en dur dans l’application, pour plus de souplesse. Après tout, vous ne savez pas à l’avance quel terminal (uniquement un simple terminal matériel, prenant en charge un codage termcap unique, peut-être?) Vos utilisateurs vont utiliser.

( Comme votre question a peu à voir avec Java ou system.in, vous pouvez reconsidérer les balises que vous utilisez. )

Vous devriez regarder dans ces deux articles, car ils sont liés à ce que vous faites.

vérifier la variable env

définir la variable d’environnement

Comme vous exécutez la console sur le serveur Unix, dans votre cas, je vous recommande également d’examiner la commande Unix attendue, qui vous permet de lire l’entrée dans l’application console et d’agir en fonction de la commande. entrée de l’utilisateur.

Voici quelques exemples d’utilisation de la commande.

exemple d’utilisation prévue