Jim Mohr's SCO Companion
Copyright 1996-1998 by James Mohr. All rights reserved. Used by permission of
Be sure to visit Jim's great Linux Tutorial web site at http://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
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. Application
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
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 an error message, and a correct
one gets 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. This means that you can have what appears to be multiple
screens and move easily between them. 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
activate 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
when 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, they exists in a kind of
stack. Although they may be positioned so that no part of any window
overlaps another 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
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. By 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
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.
Earlier 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, and so on). These are referred to as "widgets." The
two libraries are the X Toolkit Intrinsics and the Athena Widget set
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."
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
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:
-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:
-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:
-geometry 90x90-30-0 &
The four corners are thus mapped like this:
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:
-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:
-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:
-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 cornflower blue, we would enter the
-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
-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 I want the jewel at the top of the clock to be
yellow. The command would then look like this:
-bg cornflowerblue -hour red -minute white -jewel yellow &
That's not all. There are a couple of 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 options,
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 included 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 so 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.
But 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
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
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
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
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:
This would be equivalent to:
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
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 is
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:
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 foreground 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:
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:
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 resources
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, and so on), 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
or define the resource in the .Xdefaults
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 millions
of bytes! The reason that would happen is because of the way SCO
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
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
intensity. The intensity of green is 235/255 and the intensity of
blue is 215/255. What this really means is how much energy is sent to
each phosphor. For details on what phosphors are and what part they
play in displaying an image see the section on monitors in Chapter
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 preceded by a pound-sign (#).
If you don't want to specify all four hexidecimal 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 intensity of blue to 2. We might then have a
resource specification that looked like this:
What if we wanted the intensity of green to be 45, instead of 4. The
resource specification might look like this:
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. Since we have two digits for green, we also need two
digits for the red and blue. Therefore, the above example would look
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.
So where does the 20Mb come from? Well, if we represented every
color, we would need over 16 million lines because there are 256
possibilities for red, 256 possibilities green and 256 for blue.
Since 256x256x256 is already over 16 million, you can see how quickly
the size grows.
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.
Background color of
Background color of
all windows. This usually includes text, menus, buttons, icons,
and so on.
Top shadow color.
This helps to give the window a 3D appearance.
Background color of
the active window.
Foreground color of
the active window.
Active top shadow
Color of the top
shadow on the frame of the active window.
Color of the
Desktop background, 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
There are over a dozen 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
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
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 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
you 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 intensity using slide bars. If you want
to chose a color name and move the slide bar to give a slightly
different flavor to the color you can. The values that are stored in
the palettes file will be
the RGB values and not the color names.
In addition to using the RGB color model, scocolor can also use the
Hue/Saturation/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. Therefore,
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
rgb < rgb.txt
If you want to examine 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,
and so on). Therefore, if you want to change these, then change the
rgb.txt file as well.
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 it 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:
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 client that allows us to pick and choose a font to be
based on different criteria. Knowing what those criteria are is
helpful in understanding more about fonts.
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
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 characters are just tilted with no changes to their shape. In
the font shown in Figure 0-1 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 (expanded). 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-1 contains
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. Any one 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:
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.
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
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
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:
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 done so
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 is 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
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 are many different aspects of the system,
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:
Interestingly enough, this makes a link to itself in both /etc/rc2.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
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:
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:
Or, if you want to use local fonts as well, the line might look like
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:
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 then flush the cached
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 those
from the remote host scoburg, the entry might look like this:
Assuming that scoburg has their font server configured to use port
7000, changing the port is also accomplished by changing the
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
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
Moves the window to bottom of the stack
Restores the window
to its previous size
Allows the window
to be moved with keys or the mouse
Allows the window
to be resized
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:
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 than can be shown in the box,
scroll bars will appear. An icon within the icon box can be restored
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 accomplish this 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
The default resource description file is /usr/lib/X11/system.mwmrc
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
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 the 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:
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
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
The syntax for the f.exec definition is:
an example would be:
UNIXWindow _U Ctrl<KEY>u
label in each line is the symbol that will appear in the menu pane
for that entry; in this instance, 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 that are preceded by an at-sign (@). The entry then might
look like this:
@terminal _U Ctrl<KEY>u
When you specify a bitmap, mwm defaults to reading
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
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
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.
au: why is word “modifier”
above in square brackets? remove?
The entire [modifier] on the line
above will be replaced in the file. Threfore leave it as is.
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 me 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
The next type of resource that I want to talk about 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
When the f.menu function is called, mwm searches for the menu label
within the resource file. The menu definition has the follow syntax:
[mnemonic] [accelerator_key] function
[mnemonic] [accelerator_key] function
[mnemonic] [accelerator_key] function
example might look like this:
"Admin Menu" _A
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 entry
containing 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, an 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:
a window frame icon
an icon window
a window title
title area of the window frame
the window frame border
the border area (not including the title bar)
the application window (not including the window frame)
Contents can be OR'ed together to enable that behavior at different
times. For example:
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:
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:
Because there are no default button bindings, per se, you must
include all the bindings you want within the bindings sections. This
is done within the .Xdefaults
file. Examples of other button states are:
Btn1Down Press Button 1
Press and Release Button 1
Release Button 2
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 to. 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 function 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.
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 used 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:
This starts the standard Motif Window Manager. All you need to do is
change the mwm to pmwm, like this:
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 workspaces (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:
Clicking on one of the workspaces in the panner
the viewfinder to the area you want
on the autopan function
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 workarea 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 perform 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 3. 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
Whichever key is used to activate 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 determines 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 situations where two windows were the exact same size and
were 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. Arranging 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 its 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 numbered 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. You can
change the defaults for the panner in /usr/lib/X11/app-defaults/Pmwm.
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
large. I use 1:15 ratio 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 will run
If you prefer a feeling of having a single, larger workspace than 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 installation 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, it
is not a good idea to have X terminals relying on scologin. Instead,
you can edit the file /usr/lib/X11/scologin/Xservers.
There is a line:
:0 local /usr/bin/X11/X :0 -crt
As you start-up, scologin
uses several scripts to determine what to do and when to do it, all
of 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
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:
2> /dev/null &
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 needed 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 taken from /usr/lib/X11/sco/ScoSession.
Using X terminals
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 (well, not much) from what
you would get running on the system console. X-Terminals can be as
large as consoles as well as provide color.
You can configure your X-Terminal so that scologin
automatically presents you withll a login prompt every time you turn
on 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 the 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, actually 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
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
file is used to configure scologin on those X-Terminals that do
support XDMCP (or ones where you don't want to reconfigure it).
The format of the Xservers files
is the same forof X-Terminals as it is for scologin. (Makes sense
when one considersed that 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 accesses 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 will end up getting something
Xlib: connection to "siemau"
refused by server
Client is not authorized to connect to Server
Toolkit Error: Can't open
The other mechanism is to use the xhost
program to allow or deny access as needed. Since the X0.hosts
file is usually one writable by root, xhost
allows users to decided what machines can connect during their
current session. To add a machine the syntax would be:
to remove it:
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
must be on local machine to add or remove hosts.
You can also allow access by all hosts with:
However, this is counterproductive, as the whole 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 are logging in X using scologin,
a machine-readable code is placed 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 obtained 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
extract - $DISPLAY | rsh <remote_host> xauth
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:
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
The SCO Desktop
you come from a MS-Windows or Mac world, then you will be familiar
with the desktop metaphor presented by the SCO desktop (as shown in
Figure 0-3). As you would expect, there are both menus and icons to
help you access the programs and functions of your desk top. You will
find a filing cabinet to help you find your file, an envelope for
mail and even a life preserver if you need help. Like these other
desktops, you can also configure you desktop to suit your needs.
Figure 0-3 The
you begin to work with the desktop, you will see that it is loaded
with features. Unfortunately, there are too many features to cover
them all here. Instead, as with many other aspects, we are going to
just cover some of the more commonly-used features.
of the key differences is that the SCO desktop is not the all
powerful interface to the system like the Windows Desktop. In fact,
the SCO desktop is an application like anything else, such as a
terminal window. The only difference is that this application is a
lot more complex than others. Another difference is that the SCO
desktop can be turned off. That is, if you are running X Windows, you
do not need to have the desktop running at all. If you do have
it running, it does not have to fill up the entire screen. You can
configure it to behave just like other Windows that you can make
smaller to get out of the way (called iconifying them).
What's on the Desktop
may have noticed two different kinds of icons. One set of icons has a
file folder, in addition to some other kind of picture. This
indicates that this icon doesn't do much on it's own, but is a folder
containing more icons (or even more folders). The other set of icons
are essentially programs that run when you click on them. I used the
word "essentially" because it is better to say that the
icons are "objects." Clicking on them, or even dropping
other objects onto them will trigger certain actions. What
actions occur is something that you can program.
icons that you see on your desktop are referred to as objects, which
have properties and behavior, very similar to those you find under
the newer versions of Windows. Instead of just defining the program
to start a working directory as you would in MS-Windows, you define
how it behaves. For example, what should the behavior be when you
double click the icon (activate) or what happens when you drop other
object on top of it (drop)? In addition, change different object for
when the object has been activated (large and small)
take a quick look at the printer object to see how this can work. If
you were to drop a file onto this icon, that file will be printed. On
the other hand, if you were to open it (by double-clicking it or
selecting Open from the File menu) the Print Job Manager would open.
This shows you that the two ways of opening an object can initiate
two different actions.
object that behaves differently is the Object Builder. This is the
program that you use to create new objects and to edit existing
objects. This you will find in the controls folder on the desktop. If
you open the Object Builder, it will open up a blank object. However,
if you drop another object onto it, the Object Builder will start,
having loaded this object.
default behavior of the FreeSCO is that the desktop is configured to
run automatically when you start up X windows. Also, the default
behavior is to start up taking up the whole screen. This is referred
to as the root window. Learning how to change this is what we'll
get to next.
Configuring the Desktop
the behavior of the desktop: the est way to change the behavior is
through the Preferences Editor, which is found in the Controls
folder. You can also start it from the Options menu by clicking the
"Preferences Editor" entry. There are normally over 20
different things that you can configure (see Figure 0-4). Some of
these will only configure one specific aspect of the system. The Bell
icon, for example, controls characteristics of the bell such as the
frequency and duration. Other icons allow you to configure a wide
range if aspects. For example, the Tools icon is used to configure
(among others) the specific programs to start for different desktop
functions. For example, the Text editor entry defines which editor is
started when "something" needs to be edited. (This happens
in various places.) The default here is ScoEdit (a graphical editor).
I change this to vi.
others just configure the appearance of something such as the
"Desktop Appearance" icon or "Popup Menus". Here
you can define which font to use and sometimes other things such as a
background pattern to display in a specific window. One thing I
always change is in Main Desktop Behavior. The first entry is
"Desktop as root window". This defines whether the desktop
takes up the whole screen. I prefer that it doesn't so I set this to
"No". In addition, the desktop is not "nailed" to
the background. Since it is just another window, when changing your
workspace with the panner, the window containing the desktop stays
put. (However, you can changing this from within the Window menu with
using the desktop, I prefer to use the desktop like this, rather than
as my root window. This way I can work as I want without the icons
and the rest of the desktop getting in my way. However, I still have
the desktop open as a window. I then change the shape so it is a thin
strip across the top of my workspace which gives me a simple little
default desktop displays mode: specifies icons or text. The desktop
opening display method: allows you to specify with the View menu
method if icons are displayed as text or images. If set to always
inherit, new icons are displayed in the same way. Never means they
are set according to value set in "Default desktop display
aspect here that I change is the "Desktop traversal mode".
This defines whether or not a new window is open when you open up a
new desktop top. I rarely have a need to have multiple desktops open,
so I set this to "Always reuse window". Therefore, when I
open a new desktop, the contents of the first window are basically
overwritten with the contents of the new window. However, you can set
it to "Open new window" which will (as it implies) open a
The Desktop display mode defines whether the names are
displayed as icons or as text. At least, this is what the SCO
documentation says. And this is true, for the most part. However,
when you specify the names to be displayed as text, they normally
have a much smaller icon with them. Note also that when you display
the name, you get the name of the object in most cases and nothing
very descriptive. When you display the icons, the text that appears
is the title of the object and not its name. The title is something
that you can define using the Object Builder (which we will get into
"Desktop opening display method" defines the way icons are
displayed for subsequent desktops. Setting it to "Always
inherit" means that new desktops will display the icons in the
same way as the desktop from which the new one was started. Setting
it to "Never inherit" means that the appearance will be the
same as defined in "Default desktop display mode".
thing to watch is when you have configured your system to reuse the
same window for the desktops. Normally, desktops are created with
nothing in them. The exception is the Personal desktop, but that is
created by the system the first time you start the main desktop. The
personal desktop contains an icon label "Main desktop."
This will get you back to the main desktop. However, subsequent
desktops will not have this icon. If you have created several layers
of desktops, you cannot traverse back up the tree automatically.
Instead, you need to select the entry "Open main desktop"
from the File menu.
in mind that you can have multiple copies of objects wherever you
need them. Therefore, each desktop *could* contain an icon for all
the other desktops. Therefore, no matter where you were, you could
get to the desktop you wanted.
you start the desktop for the first time (normally the fist time that
you start up X), several files are created. One is your personal
"Desktop". This is all of the icons that you have placed on
the desktop and is stored in the file Personal.dt in your home
directory. You can access this desktop by clicking the desktop
looking icon labeled "Personal Desktop." (Makes sense,
huh?) The default is nothing other than another desktop looking icon
labeled "Main Desktop". Clicking this brings you back to
your start-up desktop.
this allows you to do is configure as many different desktops as you
need. Sometimes, I find that the functionality of just the folders is
not enough. Instead, I create a desktop that has all of the icons
that I needed. I then open up that desktop when I need those tools. I
rarely have more than a couple of desktops in addition to the main
one. The others are simply additional icons within icons. I rarely
find it necessary to layer them. That is, having desktops within
desktops within desktops. Instead, the few I need are placed on the
main desktop. However, you can if you wish to.
are created using the "New Desktop" entry under the File
menu. When you select this, you are given a input window so you can
input the name of the desktop. If you leave out the default extension
'.dt' the system will add it for you.
Keep in mind that the desktops are only connected logically.
They are not like directories where one desktop is inside of the
other. At least not the default. The default puts all of the desktops
into your home directory. So when the input window appears, you
simply give it another directory path. However, the default will
always be your home directory. For example, assume I create a
sub-directory in my home directory called Desktops and create the new
desktop called Admin.dt.
If I then create a desktop on top of Admin.dt,
the system will default to putting it in my home directory and not in
Desktops. However, it is just a simple matter of adding the
appropriate directory name.
in your home directory is the main desktop, stored in the Main.dt
file. This contains all of the default objects. The main desktop is
called from the personal desktop, so there is no real reason to
change it. Instead, you should make any changes to your personal
desktop. Keep in mind, however, that the system will update the
Personal.dt for you. (You
are prompted to save when you exit the desktop.) Therefore, you
shouldn't need to make any changes in the Personal.dt
file yourself. At least, not yet. Checkout the xdt3(XC)
man-page for details on configuring these files.
thing that I find very useful is that many of the functions and
folders are available from different places. For example, the basic
configuration location is the Preferences Editor. However, there are
other places on the desktop you might want to configure: something
like the bell or the keyboards. Depending on the window you have
open, you will have an Options menu at the top. Here you can define
characteristics that are specific to that window or general
characteristics such as the bell.
Note that not all windows will have the same characteristics.
For example, opening up your home directory gives you the option to
change many different characteristics. However, if you have a
scoterm window open, you can only change those options applicable to
the scoterm. (For example, the size of the font or whether or not
there are scroll bars.)
the Accessories folders are a handful of "gadgets". These
range from a calculator to a paint program to a reminder program.
There is also a calendar program, which you can use to keep track of
appointments, schedule meetings, and so on. One very nice thing about
this is that you can access other people's calendars as well. By
default, all events created in your calendar can be viewed by others.
However, you can make any event private, if you wish.
desktop window (as well as several other windows) will have a menu
item labeled Tools. The Toolsheds entry opens up a window containing
several folders. Some, like the Accessories folder, are also on the
main desktop. In these folders are a wide range of tools. It is not
easy to group them into a single category as they do some many
different things. For example, the System Commands folder gives you a
graphical interface into many of the commands on your system. The
Demonstration folder contains a handful of animated icons.
Applications entry will open up a folder containing icons for various
applications. Surprisingly, you will find icons for SCO Merge and
Wabi. This does not mean that these are installed on your
system. It just means that if you do install them, the icons are
already there. What gets placed in this folder depends on the
application. If the application does not know about the desktop
structure, you will have too install an icon by hand. (See the
section on creating objects.)
Personal Icons entry will show you the icons that you have stored in
directory in your home directory. There are two sub-directories here:
one for small and one for large icons. Note that there are no
bitmaps/icons in here by default.
may have noticed two small folder-like icons in the bottom left-hand
corner of many of the windows. One of these has an up-arrow in it.
This brings up one directory. Remember that objects are
nothing more than a set of files in a single directory. If you have a
particular folder open, you are basically showing the contents of a
particular directory. This system knows that if this is an object, it
should be displayed in a special way. When you click the icon with
the arrow, you are moved up one directory. Note that folders are
nothing more than directories. By convention, they have an ending ts.
However, you can call them whatever you like. The other icon (without
the arrow) will refresh the current window.
are created using the Object Building which you will find within the
Control folder. This is described in chapter 20 of Graphical
Environment Guide, “Creating Objects for the Desktop”.
changing an existing icon is as simple as one would hope. As I
mentioned previously, Objects react to two types of actions or
triggers. These triggers are "open” and "drop.”
Either you open up the object and trigger the open action or drop
another object onto it an trigger the drop action.
the Object Builder icon on the desktop is on object itself, it too
reacts when something is dropped on it. That something is to start
and load the object that was dropped. You can then save these objects
as a different name and edit it to your heart's content.
new objects is a fairly straightforward process. However, creating
objects as complicated as many of those provided for you is not all
that easy. Rather than making this a book on creating desktop
objects, I will refer you to Chapter 20 of the Graphical Environment
Guide, "Creating Objects for the Desktop”.
objects can be created either by copying existing objects or creating
them new. The easy way to copy an existing object is to drop the
object onto the Object Builder. When you do this you are given the
choice to load both the icons (picture) and the actions (what is done
when the icon is clicked or another object is dropped onto it). Which
you load will depend on whether it is just the icons you want to copy
or the actions of the icons.
Figure 0-5 The
an example, let's take the UNIX icon from the desktop. When it opens
up we see something similar to Figure 0-5. I recommend that very
first thing that you do is save the object under a new name. This
keeps you from overwriting the existing object. If you are logged in
as a user other than root, copying system objects won't be a problem
as you cannot overwrite them. However, if you are root and overwrite
something that the other users need, you can make yourself very
associate a program with a particular action (opening or dropping)
you "install" it using the Executable entry under the
Install menu. This brings up a dialog window which allows you to
search for the specific application you want to start. This creates
very basic actions that you can modify as you need to. You are also
asked whether this is a graphical application or not. If not, then
you are asked whether the system should wait for a key to be pressed
before continuing. This is useful for programs that will simply
display some output before returning to your prompt. An example of
this would be the df program
to display the disk free space. Normally, you enter this command and
are brought back to the prompt. If you create an object that runs df
and do not wait, it will run the command, but the window it is
displayed in will disappear as soon as the command finishes.
au: words missing below??? please
In the upper part, the trigger action is "activate" which
simply means the program started when you double click on the object.
Below is the trigger action when an object is dropped on it. The
actions created by default are fairly simple. For example, the
activate actions for a graphical program look like this:
actions are defined within the begin-finish block. In this case, all
that is done is to change directories to the current user’s
home directory, run the program /usr/bin/xv
and pass any arguments to command. You can pass arguments to the
object by selecting the object and clicking the right mouse button. A
pop-up menu will appear labeled "Activate with arguments".
If you select this entry, a window will appear in which you can input
arguments that should be passed to the program.
you said that this was a non-graphical application, the default
script looks like this:
-n '' '/bin/df $* ; xdtwait'
it is the same, with the exception of the line that actually starts
the application. First, the object changes into the users home
directory before the program is started. In this case, a shell is
started. The shell command is a built-in directive, which says to run
the user's default shell. We see the program that will be started
(/bin/df), which will then
be passed all the arguments.
all honesty, I have never done anything much more than that. On
occasion, I have installed a shell script this way and explicitly
passed arguments, However, I personally have not used any of the
advanced programming features that are available. Writing commands
are fairly straight forward, as much of it is the same syntax as
shell programs. Unfortunately, this is one area that I will have to
put off. See Chapter 25 of Graphical Environment Guide, “Writing
Desktop Commands”, for more detailed information.
The principles by X may appear overwhelming at first. By
understanding that the different aspects of X-Windows can be thought
of as 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 will need to reinstall. However, if you keep backups of all the
files that you modify, you shouldn't need to worry about
needing to reinstall.
Next: Building an Internet Server
Copyright 1996-1998 by James Mohr. All rights reserved. Used by permission of
Be sure to visit Jim's great Linux Tutorial web site at http://www.linux-tutorial.info/