LDP
/
old-www
1
1
Fork 0
Code Issues Pull Requests Releases Wiki Activity
old-www/HOWTO/Text-Terminal-HOWTO-17.html

709 lines
36 KiB
HTML
Raw Permalink Blame History

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
<META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 0.9.21">
<TITLE> Text-Terminal-HOWTO: Using the Terminal</TITLE>
<LINK HREF="Text-Terminal-HOWTO-18.html" REL=next>
<LINK HREF="Text-Terminal-HOWTO-16.html" REL=previous>
<LINK HREF="Text-Terminal-HOWTO.html#toc17" REL=contents>
</HEAD>
<BODY>
<A HREF="Text-Terminal-HOWTO-18.html">Next</A>
<A HREF="Text-Terminal-HOWTO-16.html">Previous</A>
<A HREF="Text-Terminal-HOWTO.html#toc17">Contents</A>
<HR>
<H2><A NAME="s17">17.</A> <A HREF="Text-Terminal-HOWTO.html#toc17">Using the Terminal</A></H2>
<H2><A NAME="ss17.1">17.1</A> <A HREF="Text-Terminal-HOWTO.html#toc17.1">Intro to Using the Terminal</A>
</H2>
<P> This section is about controlling the terminal-computer interface
and/or changing the terminal set-up while using the terminal. It
explains (or points to explanations of) how the user of a terminal can
control and inspect the interface and how to use various commands
provided by the device driver. It does not explain how to use the
many application programs, shells or most Linux utilities. Two
commands commonly used at the terminal are:</P>
<P>
<UL>
<LI> clear (to clear the screen)</LI>
<LI> reset (to reset the terminal</LI>
<LI> setterm -reset (alternative for "reset" in case of bug)</LI>
</UL>
</P>
<H2><A NAME="ss17.2">17.2</A> <A HREF="Text-Terminal-HOWTO.html#toc17.2">Starting Up the Terminal</A>
</H2>
<P> Of course the power must be on for the terminal to work. If you
don't see a login prompt hit the "return" (or "enter") key a few times.
Then type your account name (followed by a return/enter) and your
password when prompted for it (also followed by return/enter). Make
sure not to type all capital letters. If you do, the computer may
think that you have an old terminal that can't send lowercase letters
and the serial driver may set itself up to send only capital letters
to the terminal.</P>
<P>If nothing happens, make sure that both the host computer and the
terminal are OK. If the host computer is shut down (no power) what
you type at the terminal keyboard may appear on the screen since the
transmit and receive pins at the computer may be connected together
resulting in echoing of characters by an "off" computer. If you can't
log in when the host computer is running, see
<A HREF="Text-Terminal-HOWTO-19.html#trouble_shoot">Trouble-Shooting</A>.</P>
<H2><A NAME="ss17.3">17.3</A> <A HREF="Text-Terminal-HOWTO.html#toc17.3">Terminal (Serial) Device Driver</A>
</H2>
<P> When typing at the command line, the shell (such as the Bash
shell) is reading what you type and reacting to it. What you type
first passes thru the terminal driver part of your operating system.
This driver may translate certain characters (such as changing the
"return" character generated by the "return" key into a "new-line"
character for Linux files). It also recognizes certain control codes
which you may type at the keyboard such as ^C to interrupt the
execution of a program. It also normally echoes what you type back to
the display.
<A HREF="Text-Terminal-HOWTO-15.html#stty_">Stty</A> may be used to configure
how this terminal driver behaves, including disabling some (or all) of
its functionality.</P>
<H2><A NAME="ss17.4">17.4</A> <A HREF="Text-Terminal-HOWTO.html#toc17.4">Problems with Editors</A>
</H2>
<P> There may be some problems with using both emacs and vi on some
terminals. A few terminals have no escape key (ESC) so you may need
to type Ctrl-[ to get ESC.</P>
<H3>emacs</H3>
<P> If software flow control exists, then the ^S command in emacs will
freeze the display. The ^Q command will unfreeze the display. One
fix is to map this to another key-press by configuring emacs that way.
Some terminals have meta keys although you may need to setup the
terminal to create a meta key.</P>
<H3><A NAME="vi_k_keys"></A> vi and Cursor-Keys </H3>
<P> Vi uses the esc-key as a command to exit insert mode.
Unfortunately for most terminals the arrow-keys send an an escape
sequence (starting with the ESC character) to the host. Vi must
distinguish between these two meanings of ESC. A smart vi (such as
vim if configured for it) is able to detect the difference by noting
the time between the ESC and the next key. If it's a short time, then
it's likely that a cursor key was pressed. Use "help cursor-keys" in
vim to find out more.</P>
<P>Here's another way to fix this. On VT terminals the left-arrow-key
may be either set to send ESC [ D or ESC O D. The other arrow keys
are similar but use A, B, and C instead of D. If you're having
problems, choose ESC [ D since the "O" in the other alternative could
be interpreted by vi as a command to "Open a line". The "[" should be
interpreted by vi to mean that an arrow-key has been pressed. ESC [ D
will be sent provided "Cursor Key Application Mode" has not been set.
ESC [ D is normally the default so everything is seemingly OK. Except
that many termcaps contain a string (not the init string) which sets
what you want to avoid: "Application Mode". Editors may send this
string to the terminal when the editor starts up. Now you are in
trouble.</P>
<P>This string has the termcap code "ks" (smkx in terminfo) meaning
enable the function (and related) keys (including the arrow keys). An
application enables these keys by sending the "ks" string to the
terminal. Whoever wrote the termcap reasoned that if an application
wants to enable these keys, then they should be put into "Application
Key Mode" since this is an "application", but you don't want this.</P>
<P>The Linux console has no "ks" string so you can't fall into this trap
at the console. For other terminals you may need to edit the termcap
(or terminfo) or use another termcap entry. You need to change not
only the "ks" string but also the termcap definitions of what they
send: kd, kl, kr, ku. Then run tic to install it.</P>
<P>For vim (vi iMproved) there is a way to set it up to work OK with ESC
O D (so you don't need to edit termcap): See vim help for
"vt100-cursor-keys". You may run "gitkeys" and then press your cursor
keys to see what they send but they may be set to send something
different when you're in an editor.</P>
<H2><A NAME="slow_scroll"></A> <A NAME="ss17.5">17.5</A> <A HREF="Text-Terminal-HOWTO.html#toc17.5">Problem with Slow Scrolling </A>
</H2>
<P>The scrolling speed of the text terminal is limited by the speed
over the serial line. This limitation is good in one respect since
the scrolling speed is slow enough that you can almost read what is
scrolling on the screen before it disappears off the bottom of the
screen.</P>
<P>But there is a downside to this. For example, if you copy a large
number of files (like everything on your hard drive) and use options
to display the full name (path name) of each file copied, then the
speed limitations of the serial line may only only display 30 files per
second on the screen. But your hard drive can copy many times faster
than this but the terminal will slow down the transfer to the speed at
which it can be displayed by the terminal. It does this by
<A HREF="Text-Terminal-HOWTO-11.html#flow_control">Flow Control</A>.</P>
<P>The fix is to disable "progress" information being displayed on the
screen for cases where it slows down the "progress". If it just
updates progress numbers a few times per second or less, it shouldn't
be a problem.</P>
<H2><A NAME="bash_bug"></A> <A NAME="ss17.6">17.6</A> <A HREF="Text-Terminal-HOWTO.html#toc17.6">Bugs in Bash ? </A>
</H2>
<P> One problem still outstanding is that if certain terminal keys
send bytes with the high order bit set to 1, then Bash seems to ignore
the meaning for them as defined in a terminfo entry. This may be
because, unless one is using 7-bit ASCII, bytes with the high order
bit set to 1, may represent a non-English letter. I reported this as
a bug in Bash (but years later realized that it may not have been a
bug). Other programs such as the vim editor and the lynx browser work
OK with such keys (when they are set to use 7-bit ASCII).</P>
<P>To work around this problem, one may define what these keys should do
in Bash by putting such definitions into <CODE>/etc/inputrc.</CODE> For
example, A Wyse 60 will send D0-D3 when the arrow-keys are hit
provided the terminal is in "application key mode". After modifying
the terminfo to reflect this, they still wouldn't work on the command
line in the Bash shell. So I explicitly defined the arrow-keys in
<CODE>/etc/inputrc</CODE> like this:</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
# Arrow keys in 8 bit keypad mode: Sends d0-d3. -ap means application.
$if term=wy60-25-ap
set enable-keypad on
"\xd0": backward-char
"\xd1": forward-char
"\xd2": next-history
"\xd3": previous-history
$endif
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P>If the terminal is already in "application key mode" there's no need
to "set enable-keypad on". enable-keypad will send the terminal the
escape sequence named smkx in terminfo (which for wyse60 is \E~3
and makes the arrow keys send D0-D3). Many other applications (other
than Bash) send this without needing to be told to do so.</P>
<H3>A fixed Bash bug</H3>
<P>There have been problems with the readline interface to the Bash
shell. Bash 2.01 (1998) had a readline interface which was quite
corrupted if one used a dumb terminal. This was fixed in later
versions. </P>
<H2><A NAME="ss17.7">17.7</A> <A HREF="Text-Terminal-HOWTO.html#toc17.7">Color ls Corruption</A>
</H2>
<P> If <CODE>ls</CODE> is corrupting your terminal emulation with the color
feature, turn it off. <CODE>ls --color</CODE>, and <CODE>ls --colour</CODE> all use
the color feature. Some installations have <CODE>ls</CODE> set to use color
by default. Check <CODE>/etc/profile</CODE>, etc. for <CODE>ls</CODE> aliases.
See
<A HREF="Text-Terminal-HOWTO-15.html#ls_color">Example for ls Function</A> for how to
have <CODE>ls</CODE> do color for the console and do monochrome for terminals.</P>
<H2><A NAME="display_freezes"></A> <A NAME="ss17.8">17.8</A> <A HREF="Text-Terminal-HOWTO.html#toc17.8">Display Freezes (hung terminal) </A>
</H2>
<P> The symptom of a hung terminal is where what you type doesn't display
on the terminal (or in some cases displays but doesn't do anything).
If what you type is invisible (or does nothing) type ^Q to restart flow
(if flow control stopped it). Hanging may also be due to:<BR>
<A HREF="#sent_bin">Sent terminal binary</A> or
<A HREF="#abnormal_exit">Abnormally exited a program</A><BR>
If you didn't do any of these two, then the program you're running
could by buggy or you interaction with it fatally illegal.</P>
<P>If you want to quit the program you were running and you can't do it
by the usual methods (some programs have special keys you must hit to
exit) then try killing it from another terminal using "top" or "kill".
If the process refuses to die, then kill it with signal 9 from top (or
use "kill" on the command line). The "9" type of forced exit may leave
some temporary files lying around as well as a corrupted interface.
If this doesn't work, killing the login shell should result in a
startup of getty with a new login prompt. If all else fails, you may
need to reboot the computer or even power it down. Just rebooting may
not alter the possibly corrupted content of the serial port hardware
registers.</P>
<P>
<A NAME="ctrl_s"></A>
People new to Linux may unintentionally press Ctrl-S (^S) (or the "No
Scroll" key) which mysteriously freezes the screen (although that is
what this key is supposed to do if you use software flow-control). To
restore normal screen interaction, press Ctrl-Q (^Q). Note that
everything typed during the "freeze" gets executed but you don't see
any report of this until you hit ^Q. Thus when it's frozen, don't
type anything drastic that might destroy files, etc. One argument for
using hardware flow-control is to prevent such freezes.</P>
<H2><A NAME="corrupt_interface"></A> <A NAME="ss17.9">17.9</A> <A HREF="Text-Terminal-HOWTO.html#toc17.9">Corrupted Terminal Interface </A>
</H2>
<P> This includes the case of a "frozen display" = "hung terminal" of
the previous section.</P>
<H3><A NAME="symptoms_"></A> Symptoms and some fixes </H3>
<P> When the display doesn't look right, or when what you type doesn't
display correctly (if at all), or nothing happens when you type a
command, you may have a corrupted terminal interface. In rare cases,
when the serial port hardware gets itself corrupted, the only fix may
be to cycle power (turn off the PC and reboot). In some cases just
cycling power for the terminal will fix it. Sometimes logging in again
will solve the problem. To do this, kill the shell process running on
the terminal (or kill getty if it's running). You may do this from
another terminal. Once killed, a new getty process respawns which
hopefully will end the corruption. Recycling power (or resetting) for
the terminal may help too.</P>
<P>The corruption may be due to things such as:
<UL>
<LI>A bug in the program you're using (including a program which
erroneously assumes that you are using a terminal of type "linux")</LI>
<LI>A hardware failure (including an obscure hardware defect that
you can normally live with)</LI>
<LI>Incorrect configuration (including an error in the terminfo or
the terminal type)</LI>
</UL>
If everything was working normally but it suddenly goes bad, it may be
that the interface got corrupted by something you did. Three mistakes
you might have made to corrupt the interface are:</P>
<P>
<UL>
<LI>
<A HREF="#sent_bin">Sent terminal binary</A></LI>
<LI>
<A HREF="#abnormal_exit">Abnormally exited a program</A></LI>
<LI>
<A HREF="#ctrl_s">Typed ctrl-S by mistake</A></LI>
</UL>
</P>
<H3><A NAME="sent_bin"></A> Sent terminal binary characters </H3>
<P> Your terminal will change its characteristics if sent certain
escape sequences or control characters. It you inadvertently try to
display a binary file, it might by chance contain such sequences which
may put your terminal into some strange mode of operation or even make
it unusable. Always view or edit a binary file with programs designed
for that purpose so that this doesn't happen. Most editors and pagers
will handle binary OK so as not to corrupt the interface. Some may
display a message telling you that they can't edit binary. But you're
likely to corrupt things if you: "cat ...." or "cp .... /dev/tty.." or
run a program which sends binary output to "standard output" (unless
you redirect such output with >, etc.).</P>
<P>Corruption can also happen when using a communications program where
a remote computer may send binary to your screen. There are numerous
other ways it can happen so be prepared for it. Even a supposedly
text file could contain unwanted control codes.</P>
<P>To fix this problem reset the terminal. Type either just "reset" or
"tset" or "setterm -reset" (followed by a &lt;return&gt; of course --
what you type will likely not be readable on the screen). This will
send the reset string from the terminfo entry to the terminal. As an
alternative to this, if the correct set-up has been saved inside the
terminal then pressing a special key(s) (perhaps in setup mode) may
restore the settings. Then you might still need to use "reset" to send
the init string if you use it to set up your terminal.</P>
<H3>Reset command was broken but now fixed</H3>
<P>Note that in 2000 the "reset" command appeared to be broken for
terminals that needed "clocal" set since "reset" seemed to unset
"clocal". In 2001 it appears to be fixed so you may not need to read
the rest of this paragraph. If you have this problem, using "reset"
will only make the situation worse by disabling communication between
the terminal and computer. You will likely need to log in again and
hope the getty sets "clocal". If you see a login prompt without
asking for it, you're in luck. Otherwise see
<A HREF="#symptoms_">Symptoms and some fixes</A> for how to get a login prompt. You
should try out "reset" before you need it and use "setterm -reset" if
"reset" logs you out or otherwise doesn't work right. I submitted a
bug report in Mar. 2000 but never got a "fixed" notice.</P>
<H3>Character corruption</H3>
<P>For the case where you see strange "graphic" characters instead of
the normal ones, pressing ^O may switch back to the normal letters.
The "reset" command also does this but it resets everything else too.</P>
<P>There's the case where all letters have the wrong attribute (too dim,
bright, blinking, or even invisible :-) but the whitespace created by
tab characters is normal. This was caused by an escape sequence which
set this attribute but the attribute doesn't apply to the whitespace
created by tab characters. Fix by resetting, etc.</P>
<H3><A NAME="abnormal_exit"></A> Abnormally exited a program </H3>
<P> Large application programs (such as editors) often use the stty
command (or the like) in their code to temporarily change the stty
configuration when you are running the program. This may put the
device driver into "raw" mode so that every character you type goes
directly thru to the application program. Echoing by the driver is
disabled so that everything you see on the screen comes directly from
the application program. Thus many control commands (such as ^C) may
not work within such applications.</P>
<P>When you tell such an application to quit, the application program
first restores the stty settings to what they were before the
application program started. If you abnormally exit the program then
you may still be in "raw mode" on the command line. You should
suspect this has happened when what you type no longer displays on the
screen.</P>
<P>To get out of raw mode and restore the normal stty settings type "stty
sane". However, you must type this just after a "return" and end it
with a "return". But hitting the "return" key doesn't do the job
since the "return" code no longer gets translated to the new-line
characters that the shell is waiting for. So just type new-line (^J)
instead of "return". The "sane" terminal interface may not be exactly
the same as the normal one but it usually works. "stty sane" may also
be useful to get out of a corrupted interface due to other causes.</P>
<H2><A NAME="stty_chars"></A> <A NAME="ss17.10">17.10</A> <A HREF="Text-Terminal-HOWTO.html#toc17.10">Special (Control) Characters </A>
</H2>
<P> A number of control characters which you may type at the keyboard
are "caught" by the terminal driver and perform various tasks. To see
these control commands type: stty -a and look at lines 2-4. They are
tersely explained in the stty manual pages. They may be changed to
different control characters or disabled using the stty command. Thus
your control characters might be different than those described below.
They are used for command-line editing, interrupting, scrolling, and
to pass the next character thru transparently.</P>
<H3>Command-Line Editing</H3>
<P> While the terminal driver has a few commands for command-line
editing, some shells have a built-in real editor (such as "readline"
in the Bash shell). Such an editor is normally on by default so you
don't need to do anything to enable it. If it's available you don't
need to learn many of the following commands although they often still
work along with the command-line editor. The most important to learn
are ^C (interrupt), ^D, and how to stop scrolling.</P>
<P>
<UL>
<LI> Delete-key (shown by stty as ^?) erases the last character</LI>
<LI> ^U kills (deletes) the line</LI>
<LI> ^W deletes a word backwards</LI>
<LI> ^R reprints the line. Useful mainly on hard copy terminals ??</LI>
</UL>
</P>
<H3>Interrupting (&amp; Quit, Suspend, EOF, Flush)</H3>
<P>
<UL>
<LI> ^C interrupts. Exits the program and returns you to the
command-line prompt.</LI>
<LI> ^\ quits. Same as interrupt. Also may dump a "core" file
(which you likely have no use for) into your working directory.</LI>
<LI> ^Z suspends. Stops the program and puts it in the background.
Type fg to restart it.</LI>
<LI> ^D end of file. If typed at the command-line prompt, exits the
shell and goes to where you were before the shell started.</LI>
<LI> ^O flush (or discard). Not yet implemented in Linux (but
proposed). Sends output to /dev/null.</LI>
<LI> ^T display driver status. Not yet implemented in Linux (but
proposed). Displays a status line for the interface (number of bytes
sent, etc.).</LI>
</UL>
</P>
<H3>Stop/Start Scrolling</H3>
<P> If what you want to see scrolls off the bottom of the screen,
you may prevent this by sending a "stop" signal (^S or Xoff) to the
host (provided Xon-Xoff
<A HREF="Text-Terminal-HOWTO-11.html#flow_control">Flow Control</A> is
enabled). Send a "start signal to resume (^Q or Xon). Some terminals
have a "No Scroll" key which will alternately send Xoff and Xon or
possibly send the hardware flow control signals ?? Here's what
ctrl-S (^S) and ctrl-Q (^Q) do:</P>
<P>
<UL>
<LI> ^S stops scrolling (Xoff)</LI>
<LI> ^Q resume scrolling (Xon)</LI>
</UL>
</P>
<P>If you want to both stop scrolling and quit, use ^C. If you want to
stop scrolling to do something else but want to keep the program that
was generating the output in memory so you can resume scrolling later,
use ^Z suspend.</P>
<P>An alternative scrolling method is to pipe the output thru a pager
such as more, less, or most. However, the output might not be
standard output but could be error output which the pager doesn't
recognize. To fix this you may need to use redirection "2>&amp;1" to get
the pager to work OK. It is often simpler to just use ^S and ^Q
unless you need to scroll backwards.</P>
<P>At a PC console (emulating a terminal) you may scroll backwards by
using Shift-PageUp. This is frequently needed since the scrolling is
often too fast to stop using ^S. Once you've scrolled backwards
Shift-PageDown will scroll forward again.</P>
<H3>Take next character literally</H3>
<P> ^V sends the next character typed (usually a control character)
directly thru the device driver with no action or interpretation.
Echoed back are two ASCII characters such as ^C.</P>
<H2><A NAME="ss17.11">17.11</A> <A HREF="Text-Terminal-HOWTO.html#toc17.11">Viewing Latin1 Files on a non-Latin1 terminal</A>
</H2>
<P> Some "text" files are 8-bit Latin1 (=ISO-8859-1). See
<A HREF="Text-Terminal-HOWTO-9.html#char_sets">Character-Sets</A>. If you have a terminal that
will not display Latin1 (or don't have the Latin1 character set
installed), then certain symbols (such as a bullet) will display wrong.
When viewing manual pages (they are Latin1) you may give the option -7
to man so as to translate everything to ASCII. Are there some pagers
that make these translations ??</P>
<H2><A NAME="ss17.12">17.12</A> <A HREF="Text-Terminal-HOWTO.html#toc17.12">Eliminating Overstriking in Files</A>
</H2>
<P>If one uses the "man" command to view a manual page but instead
redirects the output to a file, that file will have overstrikes in it.
Overstrikes are where some printed characters appear bold by printing
them twice in the same location. Thus to print an overstrike
character the file contains a backspace after the character and then
the same character repeated. If this is in a file, it's fine if you
are going to print it on a printer (unless the normal output from the
printer is so darks that overstriking makes little improvement). But
it's not so good if you want to use the file to email or edit.</P>
<P>One way to get rid of the overstrikes is to use the "ul" (underline)
command. You type: ul -t dumb my_overstruck_file > output_file
The ul command converts overstrikes to bold for whatever terminal is
specified and adds escape sequences to the output_file to generate the
bold. But the terminal of type "dumb" has no escape sequences so you
get the desired result. There are other ways to do this but this is a
possible use for a terminal of type "dumb".</P>
<H2><A NAME="ss17.13">17.13</A> <A HREF="Text-Terminal-HOWTO.html#toc17.13">Inspecting the Interface</A>
</H2>
<P> These utility programs will provide information about the terminal
interface:
<UL>
<LI> gitkeys: shows what byte(s) each key sends to the host.</LI>
<LI> tty: shows what tty port you are connected to.</LI>
<LI> set: shows the value of TERM (the terminfo entry name)</LI>
<LI> stty -a: shows all stty settings.</LI>
<LI> setserial -g /dev/tty?? (you fill in ??) shows UART type, port
address and IRQ number.</LI>
<LI> infocmp: shows the current terminfo entry (less comments)</LI>
</UL>
</P>
<H2><A NAME="term_settings"></A> <A NAME="ss17.14">17.14</A> <A HREF="Text-Terminal-HOWTO.html#toc17.14">Changing the Terminal Settings </A>
</H2>
<P> The terminal settings are normally set once when the terminal is
installed using the setup procedures in the terminal manual. However,
some settings may be changed when the terminal is in use. You
normally would not give any "stty" or "setserial" commands when the
terminal is in use as they are likely to corrupt the terminal
interface. However, there are changes you may make to the appearance
of the terminal screen or to its behavior without destroying the
integrity of the interface. Sometimes these changes are made
automatically by application programs so you may not need to deal with
them.</P>
<P>One direct method of making such changes is to use the setup key (or
the like) at the terminal and then use menus (or the like) to make the
changes. To do this you may need to be familiar with the terminal.
<A NAME="setterm_"></A>
<A NAME="tput"></A> The other 3 methods send an
escape sequence from the computer to the terminal to make the changes.
These 3 examples show different methods of doing this to set reverse
video:</P>
<P>
<OL>
<LI> setterm -reverse</LI>
<LI> tput -rev</LI>
<LI> echo ^[[7m</LI>
</OL>
</P>
<H3>setterm</H3>
<P> This is the easiest command to use. It uses long options (but
doesn't use the normal -- before them). It consults the terminfo
database to determine what code to send. You may change the color,
brightness, linewrap, keyboard repeat, cursor appearance, etc.</P>
<H3>tput</H3>
<P> The "tput" command is similar to "setterm" but instead of using
ordinary words as arguments, you must use the abbreviations used by
terminfo. Many of the abbreviations are quite terse and hard to
remember.</P>
<H3>echo</H3>
<P> In the example "echo ^[[7m" to set reverse video, the
^[ is the escape character. To type it type ^V^[ (or ^V
followed by the escape key). To use this "echo" method you must find
out what code to use from a terminal manual or from terminfo or
termcap. It's simpler to use setterm or tput if you are typing on the
command line. Since "echo ..." will execute faster (since it doesn't
do any lookups) it's good for using in shell scripts which run at
start-up, etc.</P>
<H3>Saving changes</H3>
<P> When you turn off the terminal the changes you made will be lost
(unless you saved them in non-volatile terminal memory by going into
set-up mode and saving it). If you want to use them again without
having to retype them, put the commands in a shell script or make it a
shell function. Then run it when you want to make the changes. One
way to make the changes semi-permanent is to put the commands in a
file that runs each time you login or start up the computer.</P>
<H2><A NAME="ss17.15">17.15</A> <A HREF="Text-Terminal-HOWTO.html#toc17.15">Multiple Sessions</A>
</H2>
<P> The "<CODE>screen</CODE>" package runs multiple sessions something like
virtual terminals on the console: See
<A HREF="Text-Terminal-HOWTO-7.html#console_dev">The Console: /dev/tty?</A>. You can switch back and forth between the
sessions. The non-free Facet Term software also does this. See
<A HREF="http://www.facetcorp.com/ft_overview.html">FacetTerm</A></P>
<H2><A NAME="ss17.16">17.16</A> <A HREF="Text-Terminal-HOWTO.html#toc17.16">Logging Out</A>
</H2>
<P> To log out type either "logout" or "exit". Under some
circumstances your request will be refused, but you should be told why.
One reason for refusal is if you are not in the same shell that
you logged into. Another way to log out is to press ^D. Since ^D is
also used for other purposes, you may not want it to log you out. If
you set IGNOREEOF in the Bash shell then ^D will no longer log you
out.</P>
<H2><A NAME="ss17.17">17.17</A> <A HREF="Text-Terminal-HOWTO.html#toc17.17">Chatting between Terminals, Spying</A>
</H2>
<P> If two persons logged into terminals on the same host computer
want to chat with each other they may use the "write" or the "talk"
(better) program. One may prevent anyone (except the superuser) from
writing (sending messages) to their terminal by using the "mesg"
command.</P>
<P>For spying on what someone else is doing at their terminal use the
"ttysnoop" program. In "ttysnoop" the two terminals have the same
status and anything typed on either keyboard appears on both screens
(in the same location). So if you're really spying and don't want to
be detected, you shouldn't type anything.</P>
<P>"ttysnoop" can be used for training with instructor and trainee
sitting side-by-side, each at their own terminal. The instructor may
watch what the trainee is typing and can correct any mistakes by
typing it correctly. The trainee can watch what the instructor types
and then try typing it. It's just like they used one terminal with
both people having their hands on the keyboard at the same time.</P>
<P>There's one shortcoming to "ttysnoop" and that is that the terminals
involved should all be (or emulate) the same type of terminal (such as
vt100). Since the "Linux" emulation done by a console (monitor) and
the "minicom" (or "picocom") emulation are close to vt100 one may use
ttysnoop using two PCs, one running "minicom" which emulates a
terminal.</P>
<P>There's a non-free program called "DoubleVision" that is something
like ttysnoop but does much more. Terminals may be of different types
and it can remember and playback sessions on terminals so you can
observe what happened in the past. The webpage is at
<A HREF="http://www.tridia.com">http://www.tridia.com</A>.</P>
<H2><A NAME="ss17.18">17.18</A> <A HREF="Text-Terminal-HOWTO.html#toc17.18">Sharing the Serial Port</A>
</H2>
<P> It's possible to use the same serial port for both a text-terminal
and another serial device such as a printer or modem. Making the
physical connection is easy using one of these methods:
<UL>
<LI> Just unplug the terminal cable and plug in the other device</LI>
<LI> Use an AB switch to switch between the terminal and other
device (uses 3 cables)</LI>
<LI> Use the printer (or aux) port on the terminal for the other
device</LI>
</UL>
</P>
<P>When you are not using the serial port for a terminal, then you need
to make sure that no characters intended for the terminal are sent to
the other device by mistake. One unsafe way to do this is to let the
programs running on the terminal keep running, provided they don't
send out anything for the terminal when you are using the other
device. This sometimes works since a terminal running on a serial
port doesn't prevent another program (process) from opening the same
port. This sometimes works if the other device is a printer. But if
the other device should send bytes to the serial port on the computer,
then the program(s) for the terminal which are still running on the
port will often send back some bytes for the terminal which will
actually go to the other device as garbage.</P>
<P>To avoid this, it's best to kill all programs (processes) running on
the terminal before using the other device. This is not quite as easy
as it sounds. You normally have a shell (such as Bash) running on the
port and if you kill Bash (by logging out for example) then the
program "getty" will start up on the port to try to log you in again.
If you kill getty, it will respawn and start up again. So at first
glance it seems impossible to kill all processes on the terminal's
serial port.</P>
<P>One way to work around this problem is to switch runlevels so that no
getty program or shell is running on the port. For the runlevel fix,
you may create another runlevel in which no getty program runs on the
port. Then you enter this new runlevel and use the serial port for
something else. To set this up you need to edit <CODE>/etc/inittab</CODE>
and check and/or set the runlevels at which getty runs. For example
the line: <CODE>"S1:23:respawn:/sbin/getty</CODE> ..." means that getty
will run (on ttyS1) in runlevels 2 and 3. Now you could have it only
run in level 2 (by deleting "3") and then go to runlevel 3 when you
want to use the other serial device. Thus to use the serial port for
something else, the super-user would type "init 3" to switch to
runlevel 3. Type "init 2" to get back to runlevel 2. Note that each
runlevel may have a different set of initialization scripts but you
can change this if you want, so that the same scripts are run in both
runlevels. How the scripts and runlevels work are distribution
dependent. For the Debian distribution, the explanation of this is in
<CODE>/usr/doc/sysvinit</CODE>, but also look in <CODE>/usr/share/doc.</CODE></P>
<P>There's also the problem of the stty configuration of the port. When
the port is being used for the terminal it has certain configurations but
when say "init 3" is used to switch runlevels and disable getty on the
port, the original (boot-time) configuration of the port is not
restored. You are likely to wind up with the port configured in a
"raw" mode. This means that the serial port likely needs to be fully
reconfigured by stty, either by a script you write or by the next
application which runs on the port. Some applications such as
printing from the serial port may not capable of fully reconfiguring.
The obsolete version of /etc/printcap could only partially reconfigure
(but the new one under "lprng" can). Thus you might need to write a
script to do it. The stty configuration of a terminal will be
different depending on whether a shell is running on it, whether it's
at the "login" prompt, etc. Thus the stty configuration after
switching runlevels may vary.</P>
<H2><A NAME="ss17.19">17.19</A> <A HREF="Text-Terminal-HOWTO.html#toc17.19">Browsers for Text-Terminals</A>
</H2>
<P>See
<A HREF="http://www.linuxjournal.com/article/8148">2005 Text Mode Browser Roundup</A> for a review of text browsers.</P>
<P>The "lynx" browser works correctly with all text terminals. There
are some other text browsers: "w3m", "links2" (formerly "links", and
"elinks" that only work perfectly with the Linux console, xterm, or
vt100 terminals. But links2 and elinks will work with any terminal by
classifying the type as dumb like the
<A HREF="Text-Terminal-HOWTO-8.html#early_terms">first terminals</A>. However, such an interface is slower.</P>
<P>The "netrik" browser requires a color terminal. For "links2" and
"elinks" you must set your terminal to 8-bits with no parity. (I filed
a bug report years ago for elinks since it should work with parity and
finally in 2008 I got a message that it was fixed in version 0.13
and might become fixed in 0.11 and 0.12 also). All (including netrik
??) support ssl (secure socket layer) for encoded communication.</P>
<P>"w3m", "links2", and "elinks" overcome some of the "lynx" deficiencies.
"elinks" is just a more advanced "links". They can usually display
tables better and can display frames side-by-side. Unfortunately, the
width of what they try to display (for tables and frames) is often
wider than the terminal width so the text may run off the right side
of the screen. This requires scrolling sideways to see everything.
Doing this may cause the names of the table rows to disappear from the
screen. So in some cases, using "lynx" may be better.</P>
<P>Unfortunately "w3m", "links2", and "elinks" don't have numbered links
like lynx does, nor do they have good support for cookies. Support
for Javascript may be a problem. Elinks and netrik have partial
support. Links2 also has support (full ?). Both netrik and links2 has a
graphic mode for use in X Window. </P>
<P>There are still other text browser projects. Some of them seem to be
dead.</P>
<HR>
<A HREF="Text-Terminal-HOWTO-18.html">Next</A>
<A HREF="Text-Terminal-HOWTO-16.html">Previous</A>
<A HREF="Text-Terminal-HOWTO.html#toc17">Contents</A>
</BODY>
</HTML>
Reference in New Issue View Git Blame Copy Permalink