Desktop FreeBSD Part 7: Terminal Emulator Settings

To really take advantage of the best tools in computing requires that you become quite comfortable with using the command line interface (CLI). In general, nearly every task -- aside from graphical work itself -- can be accomplished from the CLI. Once the user becomes more adept at CLI work, these non-graphical tasks can be done more quickly, with more fine-grained control, and with less demand on computer resources.

Even among ordinary desktop users of FreeBSD, there are those who almost never start the X server. However, most of us simply access that part of the system through "terminal emulators," also called "terminal windows." In KDE, the typical terminal emulator is Konsole, though it is not quite the same as a console. We call them "emulators" because there is a great deal of similarity between a console and a terminal emulator, but the latter are still controlled by the X server, and the two exhibit different behaviors in general. At this point, those differences are not really important, except to note the actual console in FreeBSD cannot be made to display the full range of characters you might normally see. However, it is the differences between the various terminal emulators which matter to us.

There are two areas of configuration for the terminal emulators that contribute to ease of use: keystrokes and color text.

KEYSTROKES

We have mentioned previously Anne Barreta's guide to sane keyboard settings. Just getting your DEL and BKSP keys to work as you expect was once no simple task. What we have today is the result of a system established long ago by folks who had different hardware than is commonly available today. There were dozens of keyboards and dozens of terminal types, each with their own peculiar behaviors, and few bearing much resemblance to what the average home computer has. Most computer users today have been conditioned by one computer culture, and the folks who write Open Source were affected by another. The latter tend to preserve the defaults to what they were for that institutional equipment. That doesn't mean we ordinary desktop users can't have it our way, but that we have to do a little work to get it. However recent changes in default settings have shortened the distance.

I could not add anything to Anne's work. What I will do here is extract the most common issues for desktop users of FreeBSD 6.x. It's been my experience that for Konsole, if you choose the keyboard setting for XTerm 4, you will usually get what you expect. On the menu at the top of the Konsole window, select "Settings" and, then "Keyboard" then "XTerm (XFree 4.x.x)" (often the default setting) and you should get on the commandline a BKSP key that rubs out the previous character going backwards, and DEL will remove whatever is under the cursor. Recently, XTerm seems to copy this by default.

There are a handful of configuration files in your home directory that we call "dot files" because they are named with a dot or period at the front, which keeps them normally "hidden" out of sight. If you are having trouble with the terminal behavior of the BKSP, DEL, HOME and END keys, try Anne's recommendations for .Xdefaults and .inputrc for Bash. Chances are good it's not a problem, so we won't detail that here. With FreeBSD 6.2, when you open XTerm or Konsole on your desktop, all the keys will tend to work as you expect. In some console applications they will also work that way. Further, recent improvements in KDE's Konsole have given users more options.

However, it helps to understand what's going on behind all this. What we are doing is telling the system to translate the signals from the keyboard into certain actions. The whole thing is really quite complicated, and for the most part, over my head. The strange characters between the quotation marks in those files Anne explains are a representation of the signals coming from the keyboard under differing circumstances. If you want to see what any keystrokes do under the various terminals, first type ^V on the command line, then the keystrokes you are testing. It works for any combination that you can press at one time. This can help you decide what to put in various configuration files.

But why go to all this trouble for XTerm when Konsole is already setup? In part, it's that issue of resources again. To use Konsole takes more power than a simple XTerm, especially if you are not using KDE. To use Konsole outside KDE requires that a part of KDE be fired up. Also, there are some things in Konsole that cannot be adjusted as they can be for XTerm. For example, you may recall I stated that I have tweaked my .joerc so that I can use comfortable keystrokes to get what I want while editing. For example, if I run Joe in XTerm, I can hit CTRL+HOME and move the cursor to the top of the file. I've presented my Joe tweaks in another article.

CHARACTER SET

In order to get your less command to display more than the most basic ASCII character set, add this line to your .bashrc file:

export LESSCHARSET=iso8859

Of course, if you prefer some other language, simply take at look at the manual page ("manpage") for the less command by typing on the command line of your terminal window:

man less

and somewhere in the options you will see a list of for that. With other terminal applications, you'll need to create a file in your home directory named .login_conf (don't forget the leading period) if it's not already there and add a couple of lines like this:

me:
    :charset=iso-8859-15:
    :lang=en_US.ISO8859-15:

If your preference is not English with an extended character which includes most European language characters, then you need to check the directory at /usr/share/locale/ and you'll find a list of language groups that can be used for the :lang= line, and the options for :charset= are available in any fonts.dir file in your system display font sets:

cd /usr/X11R6/lib/X11/fonts/misc/
less fonts.dir

If you don't see anything you recognize, just match it with the suffix of your language choice, but change the format to lower case and put in the appropriate hyphens. This article is not the place to explore all the various national character sets.

COLORS

It was learned long ago that file operations were simpler if the listing of files and folders was color-coded. We learned the ls command to get a list of the files an any directory on the CLI. If you type that command, it will show the directory where you are working at the time. You can tell it to list any directory you name. For example, if you type

ls /etc

it will show the files and folders in the /etc folder. How can you tell which is a folder, and which is a file? Try adding the -G option:

ls -G /etc

and it should give you names in color: files the same as the plain text, and folders in blue. If you like this option as your default, you can give the ls command an "alias" which makes it work that way all the time. In your .bashrc, add this line at the bottom of the file:

alias ls="ls -G"

This means the ls command will always assume you want the -G option included. Please note as a procedural issue, this won't start working until you close the terminal window and restart it. To keep from doing that, you can simply type that same line on the CLI as a command with takes affect on that terminal window immediately. Keep this in mind when making changes to your .bashrc.

By default, Konsole generally allows color text display when it is called for by the choice of commands. Those colors are somewhat muted compared to other terminal emulators. Most of the colors reflect old standards long established. This was done on consoles that were black in the background, and the default text was a bright gray, not quite white. If you use a color scheme that is different from that, text colors may not work just right. When you first open a Konsole, it's usually white in background, and the text is black. I personally find this annoying and change it. Simply open the "Settings" in the Konsole menu, then "Schema" followed by "Linux colors" to get that older style.

For XTerm, you can learn something about it by typing the simple command env and seeing a list of "environment settings." One of them should included mention of TERMCAP followed by a description of the Color XTerm (xterm-color). This shows that your standard XTerm window is set up to display color text. Again, getting your XTerm to show that color-on-black schema requires putting some lines in your .Xdefaults file:

xterm*background: black
xterm*foreground: gray
xterm*cursorColor: SkyBlue
xterm*font: 9x15
xterm*ScrollBar: on
xterm*SaveLines: 2500

All of these settings are explained in detail if you can wade through the XTerm man page (man xterm). Each of these is human readable up to a point. I happen to favor a pale blue cursor block. The font is a standard terminal font and the size is appropriate for all but the smallest monitors. The SaveLines setting allows you to scroll back up a ways to see what was printed on the screen for 2500 lines. All of these can be adjusted to suit your tastes. The quickest way to learn color names for your system is to install "xcolorsel" (/usr/ports/x11/xcolorsel). This application will display blocks of color with their system names. In KDE, the KColorChooser application (under "Graphics" in the menu) will allow you to choose colors by their numerical code; simply copy the code in the small window marked "HTML" along with the hash-mark (#). For example, #00B925 will give you a nice Kelly Green on most monitors. XTerm will read that format as well for color settings.

You can also install the RxVt terminal (/usr/ports/x11/rxvt), which is a little lighter on resources than either XTerm or Konsole. It does things a little differently, such as displaying color in the man pages instead of bold and underlined text. You can study how to customize that with its own man page (man rxvt).

One final note on terminal emulators. Because we are using the Bash Shell, we have some interesting options for customizing what shows up as our prompt on the command line. I've seen some that were downright extravagant. I prefer a small amount of color coded information. If you put this line in your .bashrc:

export PS1="[33[0;36m]u@h[33[0m]w[33[1;33m]>[33[0m] "

your prompt will display the user name, the "at" symbol (@) and the name of your computer, all in cyan. The directory where you are will be displayed in the default text color, and the whole thing ends in a yellow arrow-head marker, or greater-than sign. To learn how to create your own custom Bash prompt, simply look up the Bash-Prompt-HOWTO on the Internet. You can find it wherever Linux documents are hosted. These include:

• http://www.tldp.org/HOWTO/Bash-Prompt-HOWTO/
• http://www.linuxselfhelp.com/howtos/Bash-Prompt/Bash-Prompt-HOWTO.html
• http://www.faqs.org/docs/Linux-HOWTO/Bash-Prompt-HOWTO.html

Choice Applications for the CLI

Out of the several hundred useful programs which run on the CLI, most desktop users might be interested in trying some of these:

Nano -- A standard text editor, much lighter and simpler than Joe, but also offers fewer features. It's started with the command nano and there are a few command line options. Find it at /usr/ports/editors/nano.

Midnight Commander -- A Unix clone of the old DOS Shell, Norton Commander. It displays your files in two panes, each of which can be navigated separately. If you enable mouse features, you can do a lot of point-n-click in the terminal emulator, but I've not gotten the FreeBSD console pointer to work with it. It's started by the command mc, and can be found at /usr/ports/misc/mc.

Lynx -- Previously introduced, it has been around a long time and takes some getting used to it. All webpages are displayed in linear fashion, not at all like a graphical display. However, it is quite reliable, and it's not so hard to change the default color display by editing your /usr/local/etc/lynx.cfg in the COLOR section under .h1 Appearance. I recommend you use the SSL-enabled version at /usr/ports/www/lynx-ssl, which starts like the other version with lynx.

Elinks -- In my opinion, this is the one text-mode browser most like a graphical browser in how it acts and displays. You can even enable JavaScript, though it's still not yet fully implemented. Still, the display of colors can simulate approximately what's on the graphical version of the page, along with frames and other features. The menu line at the top can be accessed by hitting your ESC key or with the mouse in a terminal window. You'll find it at /usr/ports/www/elinks and it starts with elinks on the CLI.

Another tip you may find useful: In Unix land, if you have a 3-button mouse, you can copy and paste with considerable ease. Simply press and hold your left mouse button, drag your pointer across the desired text, which highlights it, and the text is automatically transferred to the virtual clipboard. Then go to another location, press the middle mouse button, and it pastes that text there. This works across all windows and applications (mostly) when the X server is running, and in some applications can include some formatting information. However, it will not work between the X server and the actual console. Some applications which respond to mouse clicks in a terminal emulator require you to hold the SHIFT key while dragging your mouse, as well as when pasting (such as MC and Elinks).

For the brave, you can try some of these on the console before starting your X server. You may some day find it useful to be able to go to the console even while X is running. You do that by hitting the keyboard sequence CTRL+ALT+F2. There you will find a fresh login screen. If you hit F1 instead of F2 you'll find yourself on the same terminal you logged into when the machine started. Of course, on that virtual terminal, X is running, so there's no active cursor. By default, you can use the same logic to find virtual terminals all the way up to F8. To return to your running GUI session, you will find it attached to the 9th terminal: CTRL+ALT+F9. Go ahead and try it sometime; I've never seen it fail. Cycle through the virtual terminals on the keyboard until you get back to your GUI session.

This becomes most useful for desktop users when you want to build a really large package, such as OpenOffice. I've often been logged into three or four of these virtual terminals at once, working in console applications while the machine was busy building the software package. It allowed me to preserve most of the RAM for compiling and still get my work done, including online.

Ed Hurst is Associate Editor of Open for Business.