This article is participating in “Java Theme Month – Java Debug Notes Event”, see < Event link > for more details.

Question: How do I set up the environment for system. in?

I am designing a console application for a server running RedHat. End users should be able to run the application on any terminal they choose (for example; Gnome terminal, Putty SSH/Telnet, MS Telnet client, etc.)

In most terminal applications, nothing is wrong, but when I start the program from the MS Telnet session, I notice that my special inputs to system.in and system.console () are completely messed up. Backspace writes ^H to the screen, and other keys write garble.

I’ve made enough changes to it that I can keep it working, but I’m sure I’m doing badly:

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

Is this a problem for terminals that do not support Xterm? I noticed that the Microsoft Telnet client does not allow you to set the term type to Xterm before starting the session. However, once the session starts, setting TERM=xterm seems to solve the problem.

How do most console applications solve this problem?

Answer a

In character terminal applications, communication always has two terminals that must agree on how to interpret control characters. Usually both parties can use the various encodings described in the TERmcap/Terminfo database.

On the Unix server side, encoding can be defined either by setting the term environment variable or by using STTY (otherwise using the default, usually dumb terminal emulation).

On the client side, you must also set up the same terminal emulation as on the server side. Windows Native Telnet has the ability to define emulation (for example, see Configuring Telnet Terminal Type), as do other terminal emulators (such as Putty).

About your design decision: The terminal Settings described above are usually only described in user documentation rather than hard-coded in the application to maintain greater flexibility. After all, you don’t know in advance which terminal your users will use (perhaps just a simple hardware terminal that supports a TermCap encoding?). .

The article translated from Stack Overflow:stackoverflow.com/questions/3…