lsg11.htm

linux-unix130.linux.and.unix.ebooks130 linux and unix ebookslinuxLearning Linux - Collection of 12 E

<BR>



<P>After you add the term environment variables to the startup files (and you have logged out and back in to make the changes effective), you can test the term daemon and its configuration. The term program uses a daemon running in the user's memory space to manage the simultaneous demands placed on a serial port.



<BR>



<P>A test program is included with most versions of term. If the test utility is not compiled and you have a C compiler present on your system, you can compile the program with the following command:



<BR>



<BR>



<PRE>



<FONT COLOR="#000080">make term</FONT></PRE>



<P>In some distributions of Linux, the test program is already compiled. If you don't have a compiled version or a compiler, you can either search the BBSs and FTP sites for a compiled copy, or skip the testing step and start the term program (hoping for the best while you do so).



<BR>



<P>When the test program is available, run it at the command line by typing the utility's name (you should be in the directory term resides in to avoid confusion with the shell test command):



<BR>



<BR>



<PRE>



<FONT COLOR="#000080">./test</FONT></PRE>



<P>When test starts, issue the following command to test the upload capability:



<BR>



<BR>



<PRE>



<FONT COLOR="#000080">tupload ./test /tmp</FONT></PRE>



<P>This command places a copy of the test utility in the /tmp directory.



<BR>



<P>All local output from the term program is stored in the file local.log, and the remote output is stored in the file remote.log. You can examine these files if you run into problems or want to check the status of a session. You can force debugging information to these files by starting term with the following option:



<BR>



<BR>



<PRE>



<FONT COLOR="#000080">-d255</FONT></PRE>



<P>This option is handy if you have been experiencing problems and want to see the log of all transactions.



<BR>



<P>Another utility supplied with the term package is linecheck, which is useful for testing the transparency of a connection. The linecheck utility sends each of the possible 256 ASCII characters (8-bit characters, of course) over the link and verifies that they are transferred properly.



<BR>



<P>To use linecheck, you should be connected to a remote terminal using any communications package you want, such as kermit (see the procedure for using term explained in the next section). Once you have established the connection between remote and local sites, switch to the remote machine and issue the following command:



<BR>



<BR>



<PRE>



<FONT COLOR="#000080">linecheck linecheck.logfile</FONT></PRE>



<P>This command places all output of the linecheck utility in the file linecheck.logfile in the current directory on the remote system.



<BR>



<P>Then switch back to your local system and escape from the terminal mode. If you stay in terminal mode, the terminal software will misinterpret many of the characters linecheck generates. After you escape from terminal mode, issue the following command:



<BR>



<BR>



<PRE>



<FONT COLOR="#000080">linecheck linecheck.logfile &gt; /dev/modem &lt; /dev/modem</FONT></PRE>



<P>This command tells linecheck to save results in the file linecheck.logfile (in your current directory on the local system) and take all input from the modem port and send all output to the modem port.



<BR>



<P>When the linecheck utility has terminated, examine the file linecheck.logfile on both the local and remote systems. There may be a set of numbers at the bottom of the file that linecheck has determined your system can't transfer. These numbers must be specified in the term startup file called termrc in order to prevent future problems.



<BR>



<P>For example, if the linecheck utility determines that it cannot send the character with ASCII value 200 from the local to remote system, but that this value transfers properly from the remote system to the local system, place the following line in your local system's termrc file:



<BR>



<BR>



<PRE>



<FONT COLOR="#000080">escape 200</FONT></PRE>



<P>On the remote system, you must add the following line to tell the remote to ignore that ASCII value:



<BR>



<BR>



<PRE>



<FONT COLOR="#000080">ignore 200</FONT></PRE>



<P>For each escape command on one system, there should be a matching ignore command on the other!



<BR>



<P>There will probably be several characters that can't be handled both ways, primarily because some of the valid ASCII characters are reserved by the communications software as escape characters to get you between modes.



<BR>



<P>If you can't get proper output from the linecheck utility, the XON/XOFF protocol is probably getting in the way. You can disable this command and rerun the linecheck utility with the following command:



<BR>



<BR>



<PRE>



<FONT COLOR="#000080">linecheck linecheck.logfile 17 19 &gt; /dev/modem &lt; /dev/modem</FONT></PRE>



<BR>



<A NAME="E69E105"></A>



<H4 ALIGN=CENTER>



<CENTER>



<FONT SIZE=4 COLOR="#FF0000"><B>Running term</B></FONT></CENTER></H4>



<BR>



<P>The term utility is started both on the remote system and on the local systems, which means you must have copies of it properly configured both locally and remotely. Because you will want to transfer files with term, it is best to run in 8-bit mode. Start up your communications software and make sure your serial ports are set for 8-bit characters.



<BR>



<P>To use term, log in to the remote system and start up term. A useful command syntax to start term is the following:



<BR>



<BR>



<PRE>



<FONT COLOR="#000080">exec term -l $HOME/termlog -s 38400 -c off -w 10 -t 150</FONT></PRE>



<P>Although this command line may seem like a lot to type, it includes the most useful term options. You can place it in a script file or alias it (with shells that allow aliasing) to make starting the term process easier.



<BR>



<P>Use the exec command to replace the currently running shell version on the remote with term. If you don't use exec, you leave your shell running on the remote machine, which ties up memory and process time for nothing. If you are in the process of debugging a term connection or want to terminate term at some point during your session, don't use the exec command in front of term.



<BR>



<P>The -l option specifies a log file for errors. In this case, all error messages are saved in the home directory in the file termlog. You can leave off the entire option if your term session is behaving properly and switch it on only after you have encountered a problem.



<BR>



<P>The -s option specifies the speed at which to run the connection. This speed should match the speed of the modem with any on-the-fly compression systems active. For example, 38400 baud is usually possible on most 14.4kbps modems that use compression. If the speed rate is set too fast, you may lose characters. Slow down the connection if necessary. Note that most PC machines require a 16550 UART for speeds higher than 9600 baud.



<BR>



<P>The -c option turns off data compression built into term. Because this command line represents a 14.4kpbs modem with inherent compression, the term compression is turned off to prevent double compression, which doesn't gain anything for performance. If your modem speed is 9600 baud or slower with no inherent compression, use the -c on option instead to active the term compression algorithm. Compression must match at both ends of the connection.



<BR>



<P>The -w and -t options are used to optimize a fast link over a 14.4kbps (or faster) modem. They set the transmission sliding window and timeout parameters. Usually, these settings are fine and need not be altered.



<BR>



<P>After establishing the remote term session, escape from your communications software to a local session and start term on your local machine with the following command:



<BR>



<BR>



<PRE>



<FONT COLOR="#000080">term -r -l $HOME/logfile -c off -s 38400 -w 10 -t 150 &lt; /dev/modem &gt; /dev/modem &amp;</FONT></PRE>



<P>The options mean the same thing as they did for the remote process. You must add the -r option on one end of the connection, or term will instantly die. This option sets one end of the connection as the server and the other as a client. As shown in the above example, you can run the entire command (which is best saved in a script or alias) in the background, which enables you to use the terminal window for other things. The term program executes without any problem in the background.



<BR>



<P>Now term should be functioning properly. If you experience problems, examine the log files or run the test and linecheck utilities to isolate the problem. If the connection works but is very slow, check the log files to see whether they contain timeout messages. If they do, double check the configuration because that is the most likely source of problems.



<BR>



<P>The connection may seem a little jumpy (characters coming in bursts), but that is normal, especially when compression is active. For most purposes, the term session is much slower than a normal login to a remote. The real advantage to term is when you are transferring files at the same time you are moving about on the remote system.



<BR>



<P>To terminate term, you can force a fast destruction of the connection by killing the process on both ends. A better approach, which properly closes the connection, is to issue the following command:



<BR>



<BR>



<PRE>



<FONT COLOR="#000080">echo '00000' &gt; /dev/modem</FONT></PRE>



<P>As long as the string you send has five zeros, the connection will close properly. Some versions of term include the command tshutdown, which closes the term session for you. Check the distribution software. If your term version is 1.14 or higher, tshutdown should work.



<BR>



<BR>



<A NAME="E69E106"></A>



<H4 ALIGN=CENTER>



<CENTER>



<FONT SIZE=4 COLOR="#FF0000"><B>Using term with X</B></FONT></CENTER></H4>



<BR>



<P>You can use the term utility from within an X terminal window. X (or XFree86 with most versions of Linux) enables you to open a window specifically to run term. Most of the X connection handling is with a utility called txconn. You must execute the txconn program on the remote machine (connected over a network, as X doesn't work with any reasonable degree of speed over a modem) and place it in the background as a daemon. When txconn goes to the background, it returns a message containing a display number that identifies the process:



<BR>



<BR>



<PRE>



<FONT COLOR="#000080">Xconn bound to screen 11</FONT></PRE>



<P>When you connect to the remote txconn daemon from an X window, you use this number to identify the screen. You identify the screen by using the DISPLAY environment variable. If the binding was to screen 11, as shown in the preceding message, you would set the variable to



<BR>



<BR>



<PRE>



<FONT COLOR="#000080">setenv DISPLAY remotename:11</FONT></PRE>



<P>where remotename is the name of the remote machine (for the C shell). With the Bourne or Korn shell, you set the same environment variable with the following commands:



<BR>



<PRE>



<FONT COLOR="#000080">DISPLAY=remotename:11



export DISPLAY</FONT></PRE>



<P>When the term client is started in the local X window, it will connect to screen 11 on the remote machine. Because txconn knows about screen 11 on the remote, all X instructions will be transferred to the local machine's X window.



<BR>



<BLOCKQUOTE>



<BLOCKQUOTE>



<HR ALIGN=CENTER>



<BR>



<NOTE>If txconn doesn't allow you to connect or you get permission messages, you may have to issue the command xhost + on your local machine to allow the remote to open and control a window on your local session. This form of the xhost command allows any remote machine to access your windows. If you want to be sure only the remote server can open windows, use its machine name in place of the plus sign, such as xhost merlin. Alternatively, use the xauth command to control access. See the xauth man page for more information.</NOTE>



<BR>



<HR ALIGN=CENTER>



</BLOCKQUOTE></BLOCKQUOTE>



<P>You can run the local machine with windows opening on the remote system's X session using txconn, but a better approach is to use the tredir command, which is covered in the &quot;Using term Utilities &quot; section.



<BR>



<P>Running X sessions over a modem using txconn is possible, although the high amount of traffic X involves can bring even the fastest modem to a crawl. A local area network connection has enough speed to sustain X window traffic. A low-overhead version of X called LBX is available for some platforms that may help solve the overhead problem for modems. Also useful is a utility called sxpc, which compresses X protocol packets for transmission over modems. You can get sxpc with some versions of term, and it has worked well with 14.4kbps and higher speed modems, although performance is predictably slow.



<BR>



<BR>



<A NAME="E69E107"></A>



<H4 ALIGN=CENTER>



<CENTER>



<FONT SIZE=4 COLOR="#FF0000"><B>Using term Utilities</B></FONT></CENTER></H4>



<BR>



<P>The term software comes with a number of utility commands for handling file transfers. The utilities vary depending on the version of term. All these utilities require a term link to be established and functioning before you can use them.



<BR>



<P>The utilities that generally accompany term are the following:



<BR>



<UL>



<LI>The