Jim Mohr's SCO Companion


Copyright 1996-1998 by James Mohr. All rights reserved. Used by permission of the author.

Be sure to visit Jim's great Linux Tutorial web site at https://www.linux-tutorial.info/


Despite the extent it has spread in the UNIX world, the X Windows System is not a UNIX product. The X Window System, affectionately called X, was developed by the Massachusetts Institute of Technology and runs on a wide range of computers. There are even MS-Windows based versions.

The first version was developed at MIT in 1984. Several versions have been developed since, with the most current version, X version 11 (X11), being first released in 1987. X11 has been adopted as the industry standard windowing system, with the support of a consortium of major computer industry companies such as DEC, HP, SUN and IBM.

The Basics of X

An X session is usually composed of several windows, each running a separate program, or client. Like a program on any other system, programs running under X vary in functionality. Some interact completely with the user like the xterm terminal emulator. Others simply display output on the screen like the xload system monitor.

The background window is referred to as the root window. Applications windows, or clients, are displayed on top of the root window. Like UNIX processes, these windows are grouped together, or related, in a family hierarchy. Like init is the great-grandmother of all processes, the root window is the great-grandmother of all windows. Clients displayed on the root window are children of the root window and the root window is their parent. This hierarchy actually extends to different parts of a window. For example, menus are often considered children of the parent window as they inherit characteristics, but also can be configured and react independently of the parent window.

X consists of two sides: a server side and a client side. The basic functionality is similar to the way all client-server models work in that the X server has certain resources that it provides to the client. It is a common misconception that the server and clients are on the same machine. because X is integrated with the TCP/IP stacks, requests can come from any client and can be requested of any server. In addition, because X is not a program but more a protocol, machines can communicate with completely different architectures. For example, a Digital OSF/1 server can provide services to both a SCO and an AIX client, as well as either of the others providing services to the OSF/1 machine. Just like other network applications, a single machine can be both client and server.

The server acts as the interface between the client programs and the physical hardware. When you input data, either through the keyboard or pointer, the server accepts that input and is responsible for passing it along to the client. This information is passed to the client as events. Pressing a key or moving the pointer cause an event, to which the client may react. Often that reaction is in the form of changing the display on the screen. For example, a client receives the event that a particular menu was click on. It responds by requesting the server to display the pull-down menu. The server then passes the information on to the hardware, which shows the pull-down menu. As a screen, it gives it to the server, which then passes to the hardware. As a result of this separation of functionality, one client could display information on more than one server.

In order to start anything, an X server needs to be running somewhere. Despite that fact that you can access servers anywhere on the network, the most common configuration is where the server is running on the same machine as the client The two most common ways on both ODT and OpenServer are to either have scologin enabled or to use the startx shell script.

The scologin program is conceptually very similar to the way a normal login works. Although the interface is graphical, you are prompted to input your name and password. Incorrect values generate and error message and correct one get you logged into the system, just like a normal login. Also like a normal login an environment is set-up for you. If enabled, scologin will be available for you every time the system boots.

The next common way is through the startx shell script. This reads the .startxrc file in your home directory and treats it in the same way as your shell would treat the .cshrc and .kshrc files. Here is where your initial clients are started, such as terminal emulator, and the window manager If you don't have a .startxrc file in your home directory, then startx will read the system default file /usr/lib/X11/sys.startxrc. In reality, the X server is started by the xinit program. However, both scologin and startx start xinit for you.

Contrary to popular belief it is neither the X server nor the clients that are responsible for the appearance of the windows on the screen as we understand them. Instead, this falls to a window "manager." SCO provides two window managers: OSF/Motif Window Manager (mwm) and the Panning Motif Windows Manager (pmwm). Pmwm is actually an enhanced version of mwm, which provides virtual windows. Both mwm and pmwm are actually clients themselves and provide the window appearance such as their locations on the screen, borders, menus and the appropriate actions when the mouse is used or keys are pressed.

What you can do to each part of a window is important in understanding the basic concepts of X. A click is used to active a button. The is done by quickly pressing down and releasing one of the mouse buttons. Since there is only one mouse button on many systems, the mouse button used to click is usually button number one. On right handed mice, this is the left button. A double-click is where the button is clicked twice in succession. The maximum time allowed between clicks in order to be recognized as a double-click can be configured using the scomouse utility. To drag an object you select that object by placing the pointer somewhere on that object and pressing down and holding the first mouse button. In many cases, such as xterm or scoterm, you must click on the title bar. You then see the outline of that window, which you can move to its new location. You can also select the window by clicking on Move in the Window Menu. You drop an object onto another by dragging that object over another and then releasing the mouse button. This only works in appropriate circumstances. For example, dropping a document on the printer icon to print it.

If you have multiple clients on the screen, the exists in a kind of stack. Although they may be positioned so that no part of any window overlaps an other window, they are still considered to be in a stack. That is, there is one window that is considered to be on top (usually the active one) and the others are at different levels underneath. You can bring any window to the top of the stack simply by clicking on it. If, however, the windows overlap so that one or more windows are obscured, you can cycle through the windows in either direction.

Let's assume we have three clients running. They are, in order from top to bottom: A, B and C. By pressing ALT-TAB we cycle down the stack. That is, B is now on top, followed by C, with A now on the bottom. Pressing ALT-TAB again, we have C on top, then A and B is now on the bottom. If we press ALT-TAB third time, A is once again on top, followed by B, then C. This effectively takes the top of the stack and moves it to the bottom or we are selecting the next client. If we press SHIFT-ALT-TAB, the process is reversed. The bottom of the stack is brought up to the top or we are selecting the previous client.

Figure 0.1 Description of the various parts of a window

It can also be said that you, the user, manage the windows. You determine the size and location of the window, as well as determine which is the active window. Changing the size of the window is done in several different ways. My moving the pointer, you can grab any corner of the window by pressing and holding down the left mouse button. You can then move that corner in any directory, thus changing both the horizontal and vertical sizes of the window. You can also grab an edge and change either the horizontal or vertical edge, depending on what edge you grab. In addition, you can choose the Size option from the window menu and then move the pointer to the edge or corner you want to use to resize with. This time you do not hold down the left mouse button.

There are also two buttons in the upper right hand corner of the window. The outer one is the maximize button. When you click on it, the window will fill the screen (it maximizes). When you click on it again, it returns to its previous size. Not the default, but the size it was when you clicked the maximize button. The other is the iconify button. This turns the window into a miniature version of its former self. This is a "representation" of that window. These little images are referred to as icons. Double-clicking on the icon returns it to the size it was. Here again, not the default size.

When you choose which window is active you set the focus. There are two types of focus policies used: explicit and pointer. If set to explicit focus, you must click explicitly somewhere within the window to set the focus. If set to pointer focus, the focus is set when the pointer enters a window. The default is explicit focus, and I suggest you leave it until you are very familiar with moving around windows or have a compelling reason to change it. The problem with pointer focus is that you could be typing away in one window, accidentally push the mouse so the pointer is in another window. Now, all of a sudden, the new window is accepting input. On slower machines, the opposite effect might happen. You intentionally move the pointer to a new window and start typing. However, it takes a moment for the focus to "catch up" with you and therefore the input is sent to the previous window.

Common to every windowing system (at least every one I have ever seen) is the concept of a menu. Like a menu in a restaurant, a menu in X presents you a list of choices. Windows in X come in two types: pull-down and pop-up. Pull-down menus are almost universally associated with a particular location on the window. When you click on that location, a menu appears to drop down from that location. In a sense, you are pulling down that menu. By default, each window has Window Menu located in the upper left corner. This is a small square, with a horizontal bar running through it. Some people describe it as looking like a filing cabinet drawer with a handle. When you click on the Window Menu, you are give options that are related to the window itself. These include moving the window, resizing it, or changing its position in the windows "stack" (raising or lowering it).

Pop-up menus are usually not associated with any particular location on the window. These menus "pop-up" from the current cursor position. An example of a pop-up menu is the Root Menu that pops up anytime you click on an exposed area of the root window.

Above I mentioned that it was the window manager that determined the "look and feel" of an application. However, this is not entirely true. Although what we see presented is a function of the window manager, the underlying routines used to represent a button or a scrollbar, can be different. Most of the SCO provided clients use a set of routines called the X Toolkit (Xt). This is actually two libraries that are used to create the interface components (buttons, menus, etc). These are referred to as "widgets." The two libraries are the X Toolkit Intrinsics and the Athena Widget set (Xaw).

Keep in mind that X does not provide a graphical user interface (GUI). X is simply the windowing mechanism, but some other component provides the GUI. In order to produce such a GUI, the Open Software Foundation (OSF) developed the Motif Toolkit, which is based on the X Toolkit Intrinsics and a set of widgets developed by DEC and HP. This was originally designed to emulate the look-and-feel of the IBM/Microsoft Presentation Manager used in OS/2.

On ODT and OpenServer you will find both Motif and standard X applications. Motif applications are those that use the Motif Toolkit. These all have a common look-and-feel. One standard X application is the clipboard. If you run it along with some other application such as SCOEdit, you will notice some distinct difference. The most dramatic is the overall appearance. Motif based applications appear three dimensional, whereas standard X applications look "flat."

Displaying Clients

When the clients connect to the server, one of the key pieces of information it needs is the display name. The display is of the form:


The hostname identifies the name of the machine that the display is physically connected to. The most common form of hostname is simply the node name as more than likely the server is in the same network. However, it is possible to use a fully qualified domain or even an IP address for the hostname.

Unless you have some special hardware, you probably have only one physical display per server. However, each display is given a number starting at 0. If you only have one, then you are always accessing hostname:0. The screen number is only used in cases where a single keyboard and mouse are associated with multiple monitors. Like displays, screens are counted starting at 0. Since multiple screens are far less common than multiple displays, you can leave of the screen number when specifying the display. Generally, the default display is stored in the DISPLAY variable, which is then used by default. However, many X clients have a -display option, with which you can specify the display.

The important next issue is the concept of geometry. One of the advantages of a system like X is the ability to not only move windows around the screen, but to change their size and shape as well. Rather than using the window manager to change the shape of the window, we can specify the shape and size when the application is started. This is done by specifying the client's geometry.

The geometry is represented by four characteristics: width, height, distance from left or right and the distance from the top or bottom. These are referenced by width, height, xoff and yoff, respectively. Depending on the application, the height and width are measured in either pixels or characters, whereas the xoff and yoff values are measured only in pixels. Both xoff and yoff are measured in relationship to the screen. The general for of the geometry specification is:

application -geometry widthxheight+xoff+yoff

Here the + sign in front of the xoff and yoff, indicate a distance from the left and top edges of the screen, respectively. By changing the + to a -, we change the offset to be from the right and bottom instead of left and top. For example, if you wanted to start the analog clock 30 pixels to the right of the upper left hand corner, the command would look like this:

oclock -geometry 90x90+30+0 &

(It's a good idea to run all clients in the background, otherwise you don't get your prompt back until the client terminates.) Now, if we wanted to start the clock 30 pixels to the left of the upper right hand corner, the command would look like this:

oclock -geometry 90x90-30+0 &

Now, if we wanted to start the clock 30 pixels to the left of the lower right hand corner, the command would look like this:

oclock -geometry 90x90-30-0 &

The four corners are thus mapped like this:

+0+0 -0+0

+0-0 -0-0

You can also specify negative offsets that would then start the client outside of the respective edge of the screen. For example, if we change the above command to look like this:

oclock -geometry 90x90--30+0 &

It will start the client so that right edge of the clock is 30 pixels outside of the right edge of the screen. (Be careful not to have spaces in there) This does not mean that the entire clock is outside of the right edge of the screen. This is a misconception that many people have (including myself at first). On many systems, there is something magical about the upper left hand corner of the client. Offsets from the edge of the screen are in relationship to this magical corner. This is not so with X.

A +xoff value is the distance of the left edge of the client from the left edge of the screen. A -xoff value is the distance of the right edge of the client from the right edge of the screen. This also means that a +yoff value is the distance of the top of the client to the top of the screen and -yoff is the distance from the bottom of the client to the bottom screen.

Note that the geometry is specified in pairs. So, if you specify the height, you must also specify the width. Also if you specify the x-offset, you must also specify the y-offset. However, you don't have to specify the offsets if you only want to specify the size. Therefore we could start the clock like this:

oclock -geometry 90x90 &

This gives me a 90x90 clock at the default location. If we only want the offset and to take the default size, it might look like this:

oclock -geometry +100+42 &

The thing that bothers me about this clock is that it is pretty boring. The colors are drab and it really doesn't have any life to it. The nice thing is that we can change the colors. With the analog clock, there are several different things we can change. If we wanted the background color to be cornflowerblue, we would enter the command:

oclock -bg cornflowerblue &

This creates an analog clock with the default size at the default location with a background of cornflowerblue. However, it still looks boring. I want a foreground of red. So, let's run the command like this:

oclock -bg cornflowerblue -fg red &

Now it's beginning to have a little life to it. However, having both hands red is still not good enough. I want the hour hand red, but the minute hand white, and the jewel at the top of the clock I want yellow. The command would then look like this:

oclock -bg cornflowerblue -hour red -minute white -jewel yellow &

That's not all. There is a couple more options that we can use. However, these are listed in the oclock(X) man-page so you can take a look there if you want. Other clients have different option, since some of them don't make sense with an analog clock. For example, the digital clock (dclock) has an option to specify the font (-fn). Since there are no characters on the analog clock, an option to change the font wouldn't make sense.


If we wanted we could have also include the geometry along with the colors. This ends up giving us a command that is almost too long for the screen. Even now, it is a long command, that takes a long time to type in and you can easily make mistakes. One solution would be to write up everything in a shell script and start that script instead of typing everything on the command line.

The nice thing is we don't have to. X provides a mechanism to change the appearance and sometimes the behavior of a client to fit our personal preferences. This is the concept of a resource. Up to now, we have specified the resource from the command line, such as foreground color and geometry. However, there are resource files that we can edit to change the default characteristics of a given client.

Resource files for most applications are found in /usr/lib/X11/app-defaults, The general form of the resource specification is:

appname*subname*subsubname...: value

The application is usually the name of the program you are starting with the first letter capitalized. Note the word "usually." I don't know how many times I've tried to change a resource and not have it work, only to find out that this one application's name is written small. In the case of the files in /usr/lib/X11/app-defaults, there is no appname necessary as there is one file for each client and X knows what client is meant when it reads these files. If set, X will search the path specified by the XFILESEARCHPATH variable for the resource information.

Unless you want to change the system defaults, I suggest leaving these files alone. Instead you can create a user or machine specific resource file. Normally, this is $HOME/.Xdefaults-hostname, where "hostname" is the name of the host these resource specifications apply to. If this .Xdefaults file is to apply to the local host, you can leave off the hostname. If you want to specify an alternative file, you can use the XENVIRONMENT variable.

These resources are organized into classes. This allows you to set groups of individual resources all at once. Individual resources are referred to as an instance. By convention the class name begins with an upper case letter and the instance begins with a lower case. We can generally say that a resource (both class and instance) is named for the aspect of appearance that it controls. For example, there is a class called Foreground, which sets the foreground color. An instance of the Foreground class would be specified with a lowercase F: foreground. Keep in mind that different parts of the clients are affected by the class Foreground, such as the text color, cursor color, and pointer color.

Basically all applications have the following resources. In each case the class name has an initial capital. Examples of this are:



window background color



width in pixels of the window border



window border color



window foreground color

The distinction between classes and instances is very useful if we want to set several resources at once. For example, if we define the foreground color for all aspects of the scoterm, the resource definition would look like this:

ScoTerm*Foreground: blue

This would be equivalent to:

ScoTerm*foreground: blue

ScoTerm*cursorColor: blue

ScoTerm*pointerColor: blue

This means that the foreground color of text, cursor and pointer are all blue. If we then defined the pointerColor instance to be something else, only it changes. For example, if we made the following definition:

ScoTerm*pointerColor: red

color is now red, although all the others remain blue.

Although the asterisk is perhaps the most commonly used delimiters, it's not the only one. The asterisk delimiter is used to indicate a loose binding. This is where there can be several layers in the object hierarchy. It's easy to think of the asterisk as having the same function as on the command line, that is, as a wild card. Here, the asterisk represents 0 or more intermediate layers between the root object and the resource we are defining.

If there are no intermediate layers between the objects, this referred to as a tight binding. If we wanted is we could specify the binding with the asterisk, since it means 0 or more intermediate levels. However, the symbol used to explicitly specify a tight binding is a dot (.). Since I know that the level just above the pointerColor in the hierarchy is 'ansi,' I can make the specification like this:

ScoTerm*.ansi.pointerColor: red

However, since the loose binding specifier(*) can be used any place, but the tight binding specifier (.) only when appropriate, it is easier to always use the loose binding specifier.

Both the resource specifications and binding can bring up some conflicts. In the example above, we said to use blue for every foreground color related to the client "ScoTerm." We also said to use red for the foregound color of pointer. Now this seems like a conflict, which it is, however in this case the instance of the pointerColor took precedence over the class of Foreground.

Consider these lines from an .Xdefaults file:

ScoTerm*Foreground: blue

ScoTerm*pointerColor: red

ScoTerm*ansi.pointerColor: green

We first define the Foreground class to be blue. Next, we define the instance of the pointerColor to be red. Both of these are done with loose bindings. We then define the instance of the pointerColor for an ansi terminal to be green. Since tight bindings have precedence over loose bindings the pointer is green.

Taking this one set further, we change the class specification so it contains a tight binding. However, we leave the instance specification a loose binding. So, we end up with these two lines:

ScoTerm*ansi.Foreground: blue

ScoTerm*pointerColor: red

In this case, there is a tightly bound class specification that is followed by a loosely bound instance specification. When we start the scoterm, the pointer is blue, not red. In general, we can say that the more specific a specification is, the greater the precedence.

There are a limited number of options that we can use from the command line, although there are many more resources that we might want to change. In order to accommodate a large number of resource without increasing the number of options, there is the -xrm option. For example, if we wanted to change the tty modes of scoterm (what the characters are for erase, delete, quit, etc) we could do this using the -xrm option and specifying and instance of the TtyModes class. For example, to change the interrupt key from the default of DEL to CTRL-C, the command would look like this:

scoterm -xrm 'ScoTerm*ttyModes: intr ^C ' &

Keep in mind that this resource specification is only valid for this one scoterm that we are starting here. If we wanted it to be valid for all scoterms, we would either change the default in /usr/lib/X11/app-defaults or define the resource in the .Xdefaults file.


Although you may be satisfied with the default colors that X gives you, I am sure that eventually you will want you make some changes. In previous sections I talked about how you can change the color of X clients either from the command line or changing the appropriate resource. The only problem with that is you might not like the colors that SCO offers.

You might be asking, "Why doesn't SCO just give me a list with every possible color?" Well, you would need to have that list in a file somewhere. If you did, you would have a list that was well over 20Mb! The reason that would happen is because of the way SCO stores colors.

How Colors Are Represented

Each color is represented by one byte for each of the three colors: red, green, and blue. This scheme is referred to as RGB for these three colors. Each byte can have one of 256 values that represent the intensity of each color. In other words, the value represents how much of each color is to be included. If all three colors have the value 255, this is pure white. If each color has the value 0, you have black.

The /usr/lib/X11/rgb.txt file contains names of colors and often times variations in that name. This is usually the case when the name of the color actually consists of two words. For example: Antique White. In such a case, you would also find the color antiquewhite. Each entry contains the RGB values and the name of the color. For example, the antique white entry would look like this:

250 235 215 antiquewhite

This means that the intensity of red in this color is 250/255 of full intesity. The intesity of green is 235/255 and the intenisty of blue is 215/255. What this really means is how much enegry is sent to each phospor. For details on what phospors are and what part they play in displaying an image see the section on monitors in chapter 12.

If you are specifying the color as a resource (either from the command line or a resource file), you specify the color as a hexadecimal value. The key thing to note is that you must specify the value for each color, even if it is 0. Because the hexadecimal values range from 0000-FFFF, you have many more possible combinations of colors. When you do specify colors in this way, the hex string you use must be preceeded by a pound-sign (#).

If you don't want to specify all four hexidemical digits, you do not have to. However, all three colors need to be represented with the same number of digits. This is because the system would not be able to tell what value goes with what settings. If we look at an example, this will be clearer.

Let's assume we want to set the intensity of red to F, the intensity of green to 4, and the intesity of blue to 2. We might then have a resource specification that looked like this:

*background: #F42

What if we wanted the intesity of green to be 45, instead of 4. The resource specification might look like this:

*background: #F452

So what is it? Do we have red at F4, green at 5 and blue at 2? Or do we have red at F, green at 4 and blue at 52? The only way to keep things straight is if there are the same number of digits for each color.

Remember that not all video systems are created equal. You may not get the same color on your system as someone else, even if you use the exact same hex values.

Color Palettes

A key concept when dealing with colors and X is the idea of a color palette. A palette is a set of 8 colors that defines the primary portions of your windows. The characteristics are described in Table 0.1.

Each X client you start displays the colors it finds in the current palette. The colors used are configured by palette resource variables. When displaying the X client, the X server replaces the variable with the actual colors defined in the current palette. Color variables are assigned the names described in Table 0.1.


SCO Color




Background color of all windows.



Background color of all windows. This usually includes, text, menus, buttons, icons, etc.

Top shadow


Top shadow color. This helps to give the window a 3D appearance.

Active background


Background color of the active window

Active foreground


Foreground color of the active window

Active top shadow


Clor of the top shadow on the frame of the active window

Alternate background


Color of the Desktop background, the for scrollbar and sliderbar troughs and icon box background, if used



Color of a button when it is pressed

Table 0.1 Color Characteristics

The system default palettes are located in /usr/lib/X11/sco/ScoColor/palettes. There are over a dozens palettes available ranging from Chocolate (lots of browns) to Moonscape (lots of grays). You can add palettes to these defaults by using scocolor, but scocolor will do it's best to keep you from changing the default palettes. If you select any one of the palettes from in /usr/lib/X11/sco/ScoColor/palettes, then the "Delete Palette" button is disabled. Additionally, if you double click any of the buttons indicating you want to change the current color, you are prompted to input the name of a new palette.

If you really want to you can edit the /usr/lib/X11/sco/ScoColor/palettes file, but I would recommend adding more palettes. If you use scocolor, then the palettes are added to the file $HOME/.odtprefs/ascii/palettes. If you are the system administrator and want to add a palette to the system defaults, you create a palette that ends up in $HOME/.odtprefs/ascii/palettes. You then add this to the end of the system palettes file. Afterwards, this palette cannot be changed or deleted.


The primary tool for changing colors the the X-client scocolor. The file that is used to list the names of the files along with the intensity is /usr/lib/X11/rgb.txt. This is an ASCII file that you can easily edit if you know what changes you want to make.

If you add a palette or want to change one that you previously added ypu can do this in scocolor. By clicking one of the current colors, you can change the value of color. You have a choice of either a color name or specifying the intesity using slide bars. If you want to chose a color name and move the slide bar to give a slightly diffent flavor to the color you can. The values that are stored in the palettes file with by the RGB values and not the color names.

In addition to using the RGB color model, scocolor can also use the Hue/Satuaration/Value (HSV) model. I find the RGB much each to work with as it is clearer to me what is being represented. The SCO doc maintains that the HSV system is more intuitive, but I disagree. In addition, the colors are stored using the RGB values anyway.

If you want to change the names of colors or add new ones, this is done through the /usr/lib/X11/rgb.txt. However, just changing the colors is not enough. Accessing a text file is not the most efficient means of loading colors. Therfore, the system uses a color database, which is "compiled" using the rgb command. To compile the existing rgb.txt file, change directories to /usr/lib/X11 and run:

rgb < rgb.txt

If you want to examin the existing color database, this can be done with the command /usr/bin/X11/showrgb. Since it is fairly long, you might want to consider piping it through more or pg. Note that the rgb.txt file also contains the SCO default colors (scoBackground, scoHighlight, etc). So, if you want to change these, then change the rgb.txt file.


Although not applicable to every client, fonts play a major role in many applications. Defined as a set of characters for displaying text and symbols, fonts share a common appearance in terms of size, boldness, and other physical characteristics. Fonts themselves can be grouped together into font families. Additionally, font families are grouped by resolutions (dots-per-inch - DPI) into directories. So named, because they were initially stored together in the same directory in the filesystem. Each directory contains a database that the server uses to translate font names into data that the server uses to display the characters on the screen.

If the X client has a font menu like MS-Windows or Macintosh, life would be easy when in came to fonts. Instead, we need to choose the font as we are starting the application. If we were tired of the boring font use by default on scoterms, we could choose something a little fancier. Perhaps one that look like cursive. For example, we could start sco term like this:

scoterm -fn -bitstream-charter-bold-i-normal--12-120-75-75-p-74-iso8859-1

At first, this appears rather intimidating. There are over 700 fonts on an OpenServer system and learning them all is a pain. More than that, it is a waste of time. There are two utilities that make like easier for you: xlsfont and xfontsel. The xlsfont utility simply lists all the available fonts, with their complete name as we see above. The xfontsel is a real X clientthat allows us to pick and choose a font to based on different criteria. What those criteria are is helpful in understanding more about fonts.

Figure 0.2 Characteristics of the font name

The foundry is the font's developer. Here we have bitstream, which as one would guess is from the company Bitstream, the same people who develop so many fonts for MS-Windows. The font family (here charter) is a convenient way of organizing the fonts by certain appear characteristics.

The weight of a font can be thought of as its thickness. Common weights are medium and bold. The slant, as you might guess is the change in orientation of the character from the vertical. A roman slant is upright, italic is tilted, but the characters are given a slightly different shape to make them more esthetically pleasing and oblique are just tilted with no changes to their shape. Here we have an italic slant.

The set width is a general description of the average width. Common set widths are normal, condensed and double-width. The size of the font on the screen is determined by several aspects of the font name. These characteristics are the pixels, points and both vertical and horizontal DPI. Because the appearance on your screen is dependent on your monitor as well as what fonts you choose, it's safe to gauge the font size by the points. This is an old printer's measurement that represents 1/72 on an inch. Here we have 120 tenths of a pitch, therefore the size of each character is 1/6 of an inch.

One important characteristic is the font spacing. This determines whether the font is proportional or monospaced. A proportional font is one where the width of each character is different. Although this looks good on paper or in a word processor, it is not really suited for applications like terminal emulators. Better for such applications is the monospaced font, where every character takes up the same space.

The character set is basically another way of saying what letters are represented. In this example and most others in ODT and OpenServer, this field will be iso8859-1. This represents the ISO Latin 1 character set, which is a superset of the standard ASCII character set. In addition to American English characters, iso8859-1contains the special characters used in most European languages.

So now that we know what goes into font name, we can easily come up with the right font. Well, maybe. Fortunately, we don't have to. We can use wildcard for the parts of the font that we either don't think are important or want to guess at. Anyone of the specifications can be wildcarded and the system will do its best to find a match. By "do its best" I mean that there can and will be cases where multiple fonts match the specification. A rather simple example would be:

scoterm -fn '-bitstream-charter*'

On OpenServer, there are 60 matches. So, which one does the system choose? Easy enough: the first one it finds. Unless you are more specific, or know that the first one found is the one you want, you might not get the font you want. Fonts are sorted in alphabetical order, and since bold comes before medium, we get the bold version of this font instead on the medium.

Pop quiz:

Why did we enclose the font name here inside of single-quotes, although we didn't in the first example? Remember that the shell expands everything into tokens before it passes things off to the command. If we didn't use the single-quotes, the shell would try to expand it and we get a message indicating the system cannot find that font.

Life is even simpler than that. We don't need remember any long drawn out font names or try 20 different combinations to find the one we want. We can take advantage of the fact that the system understands font aliases. These are stored in the fonts directories in the file fonts.alias. These are ASCII files with the alias in the first column and the font name in the second column.

There are two things to keep mind. First, although you can edit these files and make changes, the system will not recognize the new alias unless you reset the font path with the xset command. This is simply done as:

xset fp

Next, unless you are absolutely positive about what fonts each user is using and how they are being referenced, it is not a good idea to remove aliases. If you remove an alias that some client is expecting, the results are unpredictable.

If you always want to use a particular font with a particular application, we don't need to always specify the -fn option when starting the client Since the font is just another resource, we can instead make the change to our resource definition file. An example in our .Xdefaults file might look like this:

ScoTerm*font: ibm10x20

If you looked though the directory files, you won't find a font simply named ibm10x20. This is actually an alias. However, If we wanted to specify the full name of the font, we could have like this:

ScoTerm*font: -sco-terminal-medium-r-normal--20-140-100-100-m-100-ibm437-1

Also, just like specifying the front from the command line, we can use wild cards to specify the "we-don't-cares."

The directories where the fonts are found by the server by means of the font path. This is the XFONTS variable, which defaults to /usr/lib/X11/fonts, but can be changed using the xset command. Because it is the server that is displaying the information on the screen, the font path is on the server, not on the client machine. Therefore it is important to ensure that the server is able to display a particular font before changing it for any given client. There are five sub-directories under /usr/lib/X11/fonts varying in size and appearance.

The font database in contained in the fonts.dir file in each directory. This is used when you select a font, the system knows what file to read to be able to show the proper characters on the screen. The font.dir files are ASCII files with the name of the font file in the first column and the font name in the second column. When the system is installed, the mkfontdir reads the font files found in the font path and creates the fonts.dir files. You can use mkfontdir yourself, but the details of fonts creation and management goes beyond the scope of this book.

Rather than requiring every machine on the network to have a full compliment of fonts, there is something called a font server Like a file server providing files across the network, a font server provides fonts across the network. Just like files, if the font you want is not available by the server, but is locally, there is no problem. You can access it as well.

The font server is not started by default, but can be started in one of several different ways. The first is from the command line, simply as:

/etc/fontserv start

Although this might be good for testing purposes, it is more efficient to have the fort server start up every time the system goes into multi-user mode. As will many of the different aspects of the systems this is accomplished through a script in the /etc/rc2.d directory. However, there is no script there by default. Obviously, you could write the script yourself, but you ought to let the system do it for you. This is done with:

/etc/fontserv enable

Interestingly enough, this makes a link to itself in both /etc/rc2.d and /etc/rc0.d. When the scripts in /etc/rc2.d are started they are given start as an argument, which (since the script is linked) is the same as starting it from the command line as above. It's just that the system does that automatically for us.

Starting the font server from the command line is not recommended for everyday use. In order to be able to use the fonts provided by the font server you need to tell your X session about it. The best place to do this is inside of your $HOME/.startxrc file. Although the system administrator (you?) can change the /usr/lib/X11/sys.startxrc file, so everyone using the default gets to use it, you need to remember those people that have already their own .startxrc file. Before any clients are started, you use the xset command to specify where the font server is. The general syntax is:

xset fp=tcp/server:port

The server is the name of the machine on which the font server is running, and port is the TCP broadcast port, which is 7000 by default. For example, to access the font server on the machine siemau, the command would be:

xset fp=tcp/siemau:7000

Or, if you want to use local fonts as well, the line might look like this:

xset fp=tcp/boston:7000,/usr/X11/fonts/100dpi

The font server's configuration file is /usr/lib/X11/fs/config. Here you can limit what fonts will be made available through the font server. This is done by changing the catalogue entry and specifying the fullpaths to the directories with the appropriate fonts. For example, if you only wanted to have access to the 100 dpi fonts, the line might look like this:

catalogue = /usr/lib/X11/fonts/100dpi

To make the changes take effect, either stop and restart the font server or use the /etc/fontserv command to re-read the configuration file and the flush the cached entries:

fontserv re-read

fontserv flush

Like nameservers in TCP/IP getting name information from other nameservers, you can have font server get fonts from other font servers. This is also done with the catalogue entry. For example, if I wanted to make the local 100dpi fonts available as well as the from the remote host scoburg, the entry might look like this:

catalogue = /usr/lib/X11/fonts/100dpi,tcp/scoburg:7000

Assuming that scoburg has their font server configured to use port 7000. Changing the port is also accomplished by changing the /usr/lib/X11/fs/config file. On a line by itself, add a line specifying the appropriate port. For example, if we wanted to change it to 7042, the entry would look like this:


Once the change has made, the font server needs to be stopped and restarted. If any other machines were using this server, they need to be told that it is now set for port 7042.

You can use the -cf option when starting the fontserver to specify an alternate configuration file. Reconfigure any X servers that use the font server. NOTE: Exercise care when referencing other font servers. Font server connections place a heavy demand on network resources and bandwidth. Also, be careful not to let the number of references to other font servers become so large that your system font server becomes unmanageable.

The Window Manager

Because the window manager is an important aspect of X, we need to cover it in some more details. As I mentioned earlier, OpenServer provides two window managers mwm and pmwm. The panner version is available as a separate product for ODT. Because the underlying concepts are the same, we're going to talk about them first. Later, there will be a separate section dealing with the issues related to the panner. To make things easier, I will refer to the window manager simply as mwm.

As I mentioned before, mwm is just another client. As such it has a default file: /usr/lib/X11/app-default/Mwm (Pmwm for the panning version).The following sections describe the basic default behavior of windows, icons, the icon box, input focus, and window stacking. The appearance and behavior of the window manager can be altered by changing the configuration of specific resources.

By default there are several accelerator keys that perform various functions. These functions can also be reached through the window menu. Any windows managed by mwm with have these keys. These are explicitly defined and can be changed by modifying the appropriate resource (Which we'll get to in a minute). These keys are:


Moves the window to bottom of the stack


Terminate the client


Restores the window to its previous size


Allows the window to be moved with keys or the mouse


Allows the window to be resized


Iconifies the window


Maximizes the window

The window manager is also responsible for managing icons. As I mentioned earlier, icons are small graphic representations of clients. Iconifying (turning into an icon) a client is a good way of reducing the space take up by clients that are currently not being used. Although the panner allows you to move clients from one virtual screen to another, icons are a good way of being able to instantly access a particular client. The icon box is enabled using the *useIconBox resource. This is Boolean value, so enabling it through the .Xdefaults file might look like this:

Mwm*useIconBox: TRUE

A nice thing about the icon box is that it represents all running clients and not just the ones that have been iconified. This makes finding the client you want easy, since you double-click on its icon in the icon box and it is immediately made the active window and brought to the front.

If you click on the icon once, the icon menu pops up. This is actually the same menu as the window menu. However, certain functions are disabled (grayed out). For example, since the window is already at its minimized size, the minimize option is disabled. However, you can still move the icon. In this case, restoring returns the window to it's previous size. It is often said that the window is "opened." By double-clicking on the icon, it is restored to its previous size.

If you have a lot of icons, using the icon box is a good way of managing them. The icon box is simply another client,which manages the icon images. It can be moved and resized, even iconified. If there are more icons in the icon box that can be shown in the box, scroll bars will appear. An icon within the icon box can be restore just like an icon when it's not in the icon box.

The icon box has a different window menu than the other clients. Although it does have entries to move, resize and restore the icon box itself, there are other entries that sort the icons.

One of the strong points of both window managers is the ability to configure it to our tastes. Up to now we have basically been talking about the appearance of mwm. What is really fun is to modify its behavior. One way to accomplished is through the resource description file. It contains descriptions of resources that are easily defined in the resource files. This includes such things as the behavior when buttons are pressed and the individual entries in each menu.

The default resource description file is /usr/lib/X11/system.mwmrc or /usr/lib/X11/system.pmwmrc. Here again, unless you want to institute system wide changes, I recommend copying the appropriate file into the user's home directory. It then has the name $HOME/.mwmrc or $HOME/.pmwmrc. Here is where your default menus and default bindings are defined. When you click on the root window, the root menu pops up. This is defined in the .mwmrc or .pmwmrc file and is very easy to modify to your personal tastes and preferences.

There are three types of resources that can be described here: buttons, keys and menus. It is said that window manager functions are bound to button or key press events. The relationship between the button or key press is called a binding.

Since the resource description file is an ASCII text file, we can easily edit it to make the changes we want. The format of each type of resource is slightly different, but in each case, the fields are separated by white spaces. Any text from an unquoted pound-sign (#) to then end of the line is considered a comment. Therefore, if any description needs to contain the pound-sign it must be quoted. Single characters can be "quoted" by escaping them (using the back-slash). Any line containing an exclamation mark as the first character is also treated as a comment.

When an event occurs (button or key pressed, or menu item selected), a particular window manager function is called. In general, we can say that the functions have the following syntax:

function function_arguments

There are dozens of functions that you can call, relating to everything from resizing the particular window or icon, to shuffle the order, moving, and all the other things we talked about. All of these are detailed in the mwm(XC) man-page, so I don't feel a need to cover them all. However, I will discuss some of the more common one as I describe the syntax of the resource descriptions.

The syntax for the f.exec definition is:

label [mnemonic] [accelerator_key] f.exec <arguments>{P}

an example would be:

UNIXWindow _U Ctrl<KEY>u f.exec "/usr/bin/X11/scoterm -e /bin/ksh"

The label in each line is the symbol that will appear in the menu pane for that entry, here SCOTerm. Labels containing spaces or tabs, need to be enclosed within double-quotes. For example "UNIX Window." Symbol can be a text string or it can be bitmap. This allows you to assign icons to the menu entries instead of textBitmap file names are preceded by an at-sign (@). The entry then might look like this:

@terminal _U Ctrl<KEY>u f.exec "/usr/bin/X11/scoterm -e /bin/ksh"

When you specify a bitmap, mwm defaults to reading /usr/include/X11/bitmaps. If the bitmap you want is not there, you must specify the full path. If mwm cannot find the file, it displays the entry as if it were text. If in the above example, the file was actually called, terminal.xbm, I would not see the terminal bitmap, but rather the text string "@terminal," at-sign included.

A mnemonic is a single character that is used to activate the menu option when the menu pane is visible. Contrast this to accelerator keys that are active whenever that particular window has the focus. When a mnemonic is defined it is preceded by an underline. Then, the first character in the menu label that matches the character specified will also be underlined. When the menu pane is displayed, you can activate that window function simply by pressing the key specified. Here we have _U. When displayed, the U in UNIX will be underlined.

If the function called is the no-operation function (f.nop), the function is invalid or doesn't apply in the given context, then the label is grayed out (disabled). If a function is specified that isn't one of the supported functions, then it is interpreted by mwm as f.nop.

The accelerator key syntax is:


Where [modifiers] can be things like Ctrl for the control key, Alt for the alt key and Shift for the shift key. Here we have said the accelerator key combination is CTRL-U. So, when I want to have a new UNIX window I just press CTRL-U.

Note that in contrast to button presses, key bindings to window manager functions are just for the key presses. Key releases have no meaning in this context. Also the modifiers are exclusive. That means that no other modifier key can be pressed. Since I specified just CTRL-U and not SHIFT-CTRL-U, pressing SHIFT-CTRL-U would have no effect (unless I had defined it to something already).

Choosing this combination taught be two things. First, any accelerator that is defined for the root menu is valid no matter what other window is active. Since I had included this definition within the RootMenu section of my resource file, anytime I wanted a new unix window I just pressed CTRL-U. Much of this text was typed using 'vi' from within a scoterm window. I realized that this was not a good accelerator key when I tried to move up a couple of screens in 'vi'. Remember from the section on 'vi', CTRL-U is used to move up screens. Since it is the X server that gets the keystrokes and passes them to them to the client, 'vi' never saw them. Instead I had five new scoterms. Needless to say, I changed that accelerator key rather quickly.

The next type of resource that I want to talk is also commonly modified. These are menu resources. The two functions related to menu are f.post_wmenu, which causes the windows menu to drop down and f.menu, which creates a pull-out or cascading menu. It is said that it creates a new window pane. This is similar to a pull-down menu, except that the menu starts to the right of the item that called it. For example, if one menu item calls the f.menu function, a new menu will appear to the right of that menu. If bound to a button press, the menu will appear to the right of the current pointer position.

When the f.menu function is called, mwm searches for the menu label within the resource file. The menu definition has the follow syntax.

Menu menu_name


label [mnemonic] [accelerator_key] function

label [mnemonic] [accelerator_key] function

. . .

label [mnemonic] [accelerator_key] function


An example might look like this:

"Admin Menu" _A f.menu AdminMenu

When you click on the Menu entry labeled "Admin Menu" a pull-out menu appears with the content that appear between the curly brackets. Each entry within the sub-menu is just like any other any contain f.exec, f.menu or any other functions. If you want, you can have several layers of sub-menus, but I have never found the need to have more than three. Even that was getting a little unsightly.

Each button binding has the following syntax:

button context function

The button field, describes the state that the button enters for the event to take place . For example, and entry that said <Btn1Click> would mean that button 1 was clicked. Or <Btn2Down> means that button 2 must be down.

The context is where the button must be for the button action to have an effect. The contexts are defined as follows:

Contents can be OR'ed together to enable that behavior at different times. For example:

<Btn2Down> frame|icon f.post_wmenu

This says that anytime the pointer is over a window frame or an icon and button 2 is pressed, the window menu should be posted.

The button bindings are grouped together similar to the way menu is. In general, it looks like this:

Buttons group_name


button context function

button context function

. . .

button context function


In order for these button bindings to take effect, you have to set the buttonBindings resource value to the group_name. For example, If I had a button bindings group called JimButtonBindings, the definition would look like this:

Mwm*buttonBindings: JimButtonBindings

Because there are no default button bindings, per se, you must include all the bindings you within the bindings sections. This is done within the .Xdefaults file. Examples of other button states are:

Btn1Down Press Button 1

Btn1Click Press and Release Button 1

Btn2Up Release Button 2

Btn3Click2 Double-Click Button 3

Aside from limiting where on the window a particular function is applicable, there are also limitations as to what kind of windows the function applies. For example, if the window has been iconified, minimizing does nothing as the window is already minimized. If the window is already its normal size, the restore function has no effect. Basically what happens is that if the functioned invoked has no meaning in the particular context, it is treated as a f.nop. See the mwm(XC) for a list of what functions apply in what contexts.

The Panner

First introduced as an extension product to ODT 3.0, the SCO panner is perhaps one of the most significant improvements to X since its inception. Basically, the Panner is an enhanced version of the OSF/Motif Window Manager (mwm) which is the standard window manager on ODT. It is rather trite to say that all it does is provide virtual screens fro you to work in. Although this is true, it is comparable to saying X only gives you windowing capabilities.

One of the problems I, as well as many other users face is that we often do not have the luxury of large monitors. To have more than a handful of clients running, we usually end up with them being either overlapped or sometimes completely hidden. Often to avoid clutter, we will iconify the less frequently clients to make room for others. However, this cures the symptom and not the illness. The obvious solution is to get a bigger monitor, but even that doesn't solve everything since you can't have a monitor that's infinitely large. Or can you?

This is where SCO Panner comes in. It established a virtual monitor that can be dozens of times the size of your "real" monitor. With the push of a button or click of a mouse, you move around this virtual workspace with an amount of freedom comparable to having a larger monitor. Just like virtual memory does have drawbacks over "real" memory, virtual screens have a drawback over a larger monitor. However, even if you do have a 21" monitor, the panner can provide you with even more work space.

Functionally, the panner behaves like a viewport or viewfinder into the larger virtual screen. You can move around and place your windows anywhere within the workspace. Movement can be in increments equal to the size of your "real" screen or you can move around in smaller steps, allowing finer control over what your viewfinder is currently looking at.

In order to change which window manager you use, you need to change the .startxrc or sys.startxrc file. By default the line looks like this:

exec mwm 2> /dev/null

This starts the standard Motif Window Manager. All you need to do is change the mwm to pmwm, like this:

exec pmwm 2> /dev/null

Now, start (or restart) your session and you will now have the panning Motif Window manager. When it starts you will see the panner "viewer" in the lower left hand corner (by default). It is divided into four workspace (again, by default). These are numbered 1-4. Workspace 1 is referred to as HOME and you will see this as the label, instead of a number. Between each workspace is a thin line. This is the "grid." This simply shows you the boundaries of the predefined workspaces.

Each workspace is the size of your screen and there are several ways that you can move around:

The first way of moving, clicking on one of the workspaces, will move you completely into a workspace. That is if you click on one of the work spaces, you are brought to that workspace and the viewfinder is completely within that workspace. Even if the viewfinder is over portions of multiple workareas (entirely possible), clicking on a workspace brings you there and will move the viewfinder.

If you use the ALT key and an arrow key, you are moved in that direction one "viewfinder-width". That is, if you are completely within workarea 3 and press ALT-LEFT_ARROW, you end up completely within work are 2. However, if you are halfway over workarea 3 and workarea 4, pressing ALT-LEFT_ARROW moves you to a place halfway over workarea 2 and workarea 3. There are also options in the root menu that doing panning.

The viewfinder is represented in the panner window by a gray box, the size of a work area. By pressing the left pointer button, you can drag the viewfinder to any workspace. When you release the button, you are brought to that workspace. Using this method you can move the viewfinder to a location between workspaces. I have found that the more the viewfinder resides in one workspace, the more likely it will actually move completely into that workspace. For example, if you move the viewfinder so it is 10% over workspace 2 and 90% over workspace 3, releasing the pointer button brings you completely into workspace three. The granularity of movement is defined by the *snapDistanceX and *snapDistanceY resources

Autopanning allows you to move between workspaces by simply pressing a button and moving the pointer in the appropriate direction. Autopanning is controlled by a couple of resources. The first, autoPanStep, is also used to enable and disable autopanning. This resource determines the percentage of the screen size the viewfinder moves when autopanning. Setting it to 0 means autopanning is disabled.

Which key is used to active panning with mouse movements, is defined by the *autoPanModifier resource. By default this is set to the Meta (Alt) key. If this is not set, then any time the mouse bumps against the edge of the viewfinder, it will pan. I suggest leaving the default or selecting some other key, but do not remove this resource. If it is not set, then any time you accidentally bump against the viewfinder, your view is thrown out of whack. How long the panner must wait after autopanning before the next pan is allow is defined by the autoPanRepeatSensitivity.

If autopanning is enabled (that is, AutoPanStep > 0 ), the *autoPanStartOn determine whether autopanning must be first turned on or not before you can use it. The default is True, so that whenever pmwm starts and AutoPanStep is greater than 0, autopanning is activated. Otherwise you must enable it from the root menu or by pressing ALT+SHIFT+minus. The panning can also be turned off from the root menu or by pressing ALT+minus.

One concept new to the panner is the idea of nailed windows. Nailed windows stay put. That is, if you change your work area, they follow you. Hmmm. If they stay put, they follow you. Now, that's a contradiction if I ever heard one. Believe me, that's the way I felt, too. However, think of it not as the windows being nailed to the panner as a whole, but rather the viewfinder. If they are nailed to the viewfinder and you move the viewfinder, they stay within your view.

Aside from allowing you to move from workspace to workspace, the panner allows you to move clients between different workspace. When the panner has the focus, you can use pointer button 2 to drag a window to a new workspace. The nice thing is that regardless of how they are stacked, all windows will appear with the workspace view in the panner. Therefore, you can grab any window and move it. I have run into situation where two windows were the exact same size and where in the same position. In this case, it was impossible to figure out which window would be grabbed.

If you don't like the numbers given to the workspaces, you can change them with the *workAreaNames resource. This is what is used to name workspace 1 to home. If you arrange your workspaces by function, this is a good way of keeping track of what is where.

The panner window is just like any other window. There are resources to name it, change it color and define its geometry. Like other windows, you can change the size of the panner window. One side-effect of changing the size of the panner window is that you change the number of workspaces. By default, there is a single row of four workspaces. You can make the panner window longer, thereby increasing the number of workspaces, or you can make it taller, also increasing the number of workspaces. If you make it taller, then the windows are number left to right across the top row and continue in the second and subsequent rows. If you don't like the horizontal appearance of the panner, you can make it vertical, by simply changing the shape of the window. You cannot resize the panner window so that the workspaces with windows in them are removed.

For example, assume we have a workarea that is 3 rows of four workspaces each. If we place a window in workspace 12 (the lower right corner) we can no longer decrease the size in either direction. If we move the window to workspace 8 (right most window in middle row) we can decrease the number of rows, but not the number of columns. However, you can disable this by setting the *pannerResizeNoHide resource to FALSE.

By default the panner map has a scale of 1:10. That is the height of each workspace in the panner is 1/10th that of a real workspace. This is defined by the *pannerScaleFactor resource. Unless you have a lot of clients in each workspace, then I feel that a 1:10 scale is too big. I use 1:15 because it allows me to identify all the clients in each workspace, but still doesn't take up too much room. Anything higher and the individual windows in each workspace run together.

If you want more of a feeling of having a single, larger workspace that a lot of little workspaces tacked together, you can turn off the grid by setting the *pannerShowGrid resource to FALSE.


The scologin program is actually a "display manager” since is displays the graphical login on more than just the system console. If you are running on X terminals, it is scologin that allows you to login. In principle, it serves the same functions as both getty and login.

Normally, scologin is started from /etc/rc2.d/P86scologin and runs on the second multiscreen, /dev/tty02. During the install of OpenServer, you are given the option of enabling or disabling it by default. I prefer to start X on my own, therefore I always have it disabled. However, if you have X terminals relying on scologin, this is not a good thing to do. Instead, you can edit the file /usr/lib/X11/scologin/Xservers. There is a line saying:

:0 local /usr/bin/X11/X :0 -crt /dev/tty02

As you start-up, scologin uses several scripts to determine what to do and when to do it, all which reside in /usr/lib/X11/scosession. The first, Xstartup defines what scologin should do before beginning the user's session. Next comes Xsession-<shell>, where <shell> is the user's login shell. This defines the basic characteristics of the user's X session. Xreset defines the actions when the users ends a session.

One thing to keep in mind is that the Xstartup script is run as root. As such, anything you put in there is run as root. This has the potential of becoming a security hole. Note that by default, you don't have to worry too much, as Xstartup is empty, just waiting for the eager system administrator to fill it up. One thing the Xstartup file is useful for is on X-terminals. Since they have no disk of their own, it is probably necessary to mount the filesystem containing the user's home directory.

It is only after that scologin has run through the Xsession files that it starts the X server. This is done with by running startx script with the -t. The Xsession-<shell> script that is run, behaves like a user's .profile or .login file, in that it sets up variables and other aspects of the user's environment.

In the SCO documentation you "are strongly urged to use scosession to control the clients." Their point is that if you start them out of either $HOME/.startxrc or /usr/lib/X11/sys.startxrc, you may miss certain aspects of that (or other clients), which may result in the loss of some functionality. Quite true. However, I have gotten around this.

First, I copied /usr/lib/X11/sys.startxrc to $HOME/.startxrc, which is a good idea anyway. I next comment out the lines that tested for the existence of /usr/bin/X11/scosession and if it was there, ran it. Instead, I just run the two lines that start a scoterm and the window manager:

exec scoterm 2> /dev/null &

exec pmwm 2> /dev/null

This way I still start all the clients the way SCO "wants”, but I don't have scosession. So, just what does scosession do? First, it's name implies it is responsible for the startup and shutdown of the X server. The configuration files for scosession are in $HOME/.odtpref/ScoSession with the standard X resource information in /usr/lib/X11/ScoSession. One nice thing about scosession is that it remembers what you were doing the last time. When you start up the next time, you are prompted to resume the saved session or start a new one. The file $HOME/.odtpref/ScoSession/dynamic contains the information that was saved from the previous session. That is, what is need to configure your session when you decide to resume that last session. The static file contains the resource settings that define your default session. If this file doesn't exist, the resource information is take from /usr/lib/X11/sco/ScoSession.

Using X terminals

As their name implies, X terminals are terminals the run X. In principle, they function the same way as normal terminals. The X terminal is responsible for communicating with other devices as well as displaying the incoming information on the screen. The major difference (I hope you already guessed) is that the interface is all graphical. The appearance is no different (not much) from what you would get running on the system console. X-Terminals can be as large as console as well as provide color.

You can configure your X-Terminal so that scologin automatically presents you will a login prompt every time you turn the terminal. Like "normal” terminals, you are connected to a host machine where the programs (in this case X clients) are running. To aid in the communication between host machine and X-Terminal, SCO can use the X Display Manager Control Protocol (XDMCP), provided the X-Terminal can use it. One advantage this has is that connection is immediately re-established to the host when the terminal is turned back on, and you see the login prompt waiting for you.

If the X-Terminal does not understand XDMCP, you must include an entry for that terminal in the /usr/lib/X11/scologin/Xservers file. Otherwise you don't have to configure the host at all. Instead, the XDMCP communicates with the SCO machine and hooks you up. In addition, the terminal must be left powered on at all times to maintain the connection to the host machine. If you turn it off, you must manually reconnect it to the host.

On the X-Terminal side of things, there are two ways of configuring things. Well, three. The first is using XDMCP. If the X-Terminal uses it, there may be no configuration needed. However, if there is, you have to determine how the X-Terminal is to contact the host, as some broadcast a request for a host. When there is an answer, they will display a list of available hosts from which you can choose. Others broadcast a request and just accept the first available host.

Once you login, the behavior is the same as if you were on the system console. If there is an .Xdefaults file in your home directory that matches the name of the host that you connect to, these will be the defaults used.

The /usr/lib/X11/scologin/Xservers file is used to configure scologin on those X-Terminal that do support XDMCP (or ones where you don't want to reconfigure it). The format of the Xservers files is the same of X-Terminals as it is for scologin. (Makes sense when one considered you get a scologin on the X-Terminal.

Security and Authorizations

Because of its very nature, X is not very secure. It sits on a network, which means that potentially everyone on your network has access to your machine. This applies to X or any other network application. The problem is compounded further by X's design. It was intended to be accessible by others. If you know the name of the machine, theoretically you could display any client on someone else's machine. In fact, you could essentially take over control of that machine including taking over the mouse and even killing the other person's clients. Fortunately, there aren't any such bad willed people that perform such senseless acts of aggression. Yeah, right.

Although we haven't yet figured out how to make X completely secure (other than disconnecting it from the network), there are several mechanisms that we can use to limit the access to our machine. The first is based on which host is trying to contact you and is specified through the files /etc/X?.hosts, where ? is the display number. Since you more than likely have only one display, we are only going to talk about X0.hosts. However, what we talk about will be applicable to any display.

By default, the server only access clients that are running on the local machine. If we want to add a machine we either add the machine's name to X0.hosts or we use the xhost program. The X0.hosts file is a simple text file containing a list of the hosts that are authorized to connect. For example, the X0.hosts file on scoburg might look like this:




Normally, this is sufficient, but in some cases you might need to include the domain name as well. If any other host tries to start a client on scoburg's display, they're end up getting something like this:

Xlib: connection to "siemau" refused by server

Xlib: Client is not authorized to connect to Server

X Toolkit Error: Can't open display: siemau:0

The other mechanism is to use the xhost program to allow or deny access as needed. Since the X0.hosts file is usually one writeable by root, xhost allows users to decided what machines can connect during their current session. To add a machine the syntax would be:

xhost +hostname

and to remove it:

xhost -hostname

Note that you cannot add hosts to a remote machine. For example, you cannot telnet to a machine and run xhost. If you try, you end up getting a message like this:

scoburg being added to access control list

xhost: must be on local machine to add or remove hosts.

You can also allow access by all hosts with:

xhosts +

However, this is counterproductive as the who idea here is to limit access to your machine.

Another access control method is the well-named MIT-MAGIC-COOKIE-1. Why is it well named? Come on! It's a great name! Despite any "logic" behind the name, I think it's fantastic.

When you logging in X using scologin a machine-readable code is place in $HOME/.Xauthority. This code is called a magic cookie and is 128 bits long. The magic cookies can be thought of as a password that is only known to the server and the user logging in with scologin. Unlike regular passwords, users don't actually type in the password, but rather users run programs to manipulate it. Once established, a client has to present this password (code) in order to access the server. The code is obtain by reading .Xauthority, but since it is (by default) only readable by the owner, only the user can access it.

With a shared home directory (such as one using NFS) the .Xauthority file is available to you. If you are on another machine, you need to use the xauth program to raid the cookie jar on the other machine to extract the information and merge it with your own. However, If you don't have access to the remote .Xauthority file this won't work. One solution is user equivalence that we talked about in the section on networking. The other is .rhosts. Both allow you to define which users and from which machines can access the .Xauthority file. However, this also opens other things up.

If you are on the local machine and want to update the .Xauthority file somewhere else, you would run xauth like this:

xauth extract - $DISPLAY | rsh <remote_host> xauth merge -

The basic syntax for xauth is:

xauth <flags> <function> <options>

If we use the add, merge, or extract functions, then we need to specify the server. In the first half we are extracting the authority information from whatever machine we have defined with the DISPLAY variable, which is normally the local host. The dash (-) here says we want to write the output to stdout. If we wanted we could extract the information from another host by using that name, provided the information was in the .Xauthority file. Because we did not use the -f option to specify what file to read, the system uses the file in the XAUTHORITY variable, which usually defaults to $HOME/.Xauthority.

In the second half, we are running rsh on the remote host and merging the authorization information. Here the dash means we are reading from stdin. We can also extract the authorization information for a remote machine and merge it with the .Xauthority file on a different machine. The syntax would be:

xauth extract - vesta:0 | rsh scoburg auth merge -

We can now take this one step further and extract the authority information from a remote machine and merge it with the information locally. Again, assuming we are on siemau and want to extract the authority information on scoburg, the command would be:

rsh scoburg xauth extract - scoburg:0 | xauth merge -

What Now?

The principles by X may appear overwhelming at first. By understanding that the different aspects of X-Windows can be though of different layers building on each other, it's easier to understand their interactions. My suggestion now is to play around with your X system and make some changes and see how the changes effect the behavior and appearance of your windows and the entire work area. Don't worry, too much. The worst that can happen is that you need top reinstall.

Next: Talking to Other Machines


Copyright 1996-1998 by James Mohr. All rights reserved. Used by permission of the author.

Be sure to visit Jim's great Linux Tutorial web site at https://www.linux-tutorial.info/