[0m


X(1)		    UNIX Programmer's Manual		     X(1)



[1mNAME
     [0mX - a portable, network-transparent window system

[1mSYNOPSIS
     [0mThe X Window System is a network transparent window system
     developed at MIT which runs on a wide range of computing and
     graphics machines.  The core distribution from MIT has sup-
     port for the following operating systems:

			 Ultrix 3.1 (Digital)
			  SunOS 4.0.3 (Sun)
		     HP-UX 6.5 (Hewlett-Packard)
		      Domain/OS 10.1 (HP/Apollo)
			   A/UX 1.1 (Apple)
		    AIX RT-2.2 and PS/2-1.1 (IBM)
			    AOS-4.3 (IBM)
			 UTEK 4.0 (Tektronix)
		   NEWS-OS 3.2 (Sony; client only)
		   UNICOS 5.0.1 (Cray; client only)
     UNIX(tm) System V, Release 3.2 (AT&T 6386 WGS; client only)

     It should be relatively easy to build the client-side
     software on a variety of other system.  Commercial implemen-
     tations are also available for a wide range of platforms.

     The X Consortium requests that the following names be used
     when referring to this software:

				  X
			   X Window System
			     X Version 11
		     X Window System, Version 11
				 X11

     _X _W_i_n_d_o_w _S_y_s_t_e_m is a trademark of the Massachusetts Insti-
     tute of Technology.

[1mDESCRIPTION
     [0mX Window System servers run on computers with bitmap
     displays.	The server distributes user input to and accepts
     output requests from various client programs through a
     variety of different interprocess communication channels.
     Although the most common case is for the client programs to
     be running on the same machine as the server, clients can be
     run transparently from other machines (including machines
     with different architectures and operating systems) as well.

     X supports overlapping hierarchical subwindows and text and
     graphics operations, on both monochrome and color displays.
     For a full explanation of the functions that are available,
     see the _X_l_i_b - _C _L_a_n_g_u_a_g_e _X _I_n_t_e_r_f_a_c_e manual, the _X _W_i_n_d_o_w
     _S_y_s_t_e_m _P_r_o_t_o_c_o_l specification, the _X _T_o_o_l_k_i_t _I_n_t_r_i_n_s_i_c_s - _C



Printed 25/2/93             Release 4				1






X(1)		    UNIX Programmer's Manual		     X(1)



     _L_a_n_g_u_a_g_e _I_n_t_e_r_f_a_c_e manual, and various toolkit documents.

     The number of programs that use _X is growing rapidly.  Of
     particular interest are: a terminal emulator (_x_t_e_r_m), a win-
     dow manager (_t_w_m), a display manager (_x_d_m), a session
     manager (_x_s_m), mail managing utilities (_x_m_a_i_l and _x_b_i_f_f), a
     manual page browser (_x_m_a_n), a bitmap editor (_b_i_t_m_a_p), access
     control programs (_x_a_u_t_h and _x_h_o_s_t), user preference setting
     programs (_x_c_o_n_t_r_o_l, _x_r_d_b, _x_s_e_t, _x_s_e_t_r_o_o_t and _x_m_o_d_m_a_p), a
     load monitor (_x_l_o_a_d), clocks (_x_c_l_o_c_k and _o_c_l_o_c_k), a font
     displayer (_x_f_d), utilities for listing information about
     fonts, windows, and displays (_x_l_s_f_o_n_t_s, _x_f_o_n_t_s_e_l, _x_l_s_w_i_n_s,
     _x_w_i_n_i_n_f_o, _x_l_s_c_l_i_e_n_t_s, _x_d_p_y_i_n_f_o, and _x_p_r_o_p), a diagnostic for
     seeing what events are generated and when (_x_e_v), screen
     image manipulation utilities (_x_w_d, _x_w_u_d, _x_p_r, and _x_m_a_g), and
     various demos (_x_e_y_e_s, _i_c_o, _m_u_n_c_h_e_r, _p_u_z_z_l_e, _x_g_c, etc.).

     Many other utilities, window managers, games, toolkits, etc.
     are available from the user-contributed software.	See your
     site administrator for details.

[1mSTARTING UP
     [0mThere are two main ways of getting the X server and an ini-
     tial set of client applications started.  The particular
     method used depends on what operating system you are running
     and on whether or not you use other window systems in addi-
     tion to X.

     _x_d_m [1m(the X Display Manager)
	     [0mIf you want to always have X running on your
	     display, your site administrator can set your
	     machine up to use the X Display Manager _x_d_m.  This
	     program is typically started by the system at boot
	     time and takes care of keeping the server running
	     and getting users logged in.  If you are running
	     _x_d_m, you will see a window on the screen welcoming
	     you to the system and asking for your username and
	     password.	Simply type them in as you would at a
	     normal terminal, pressing the Return key after each.
	     If you make a mistake, _x_d_m will display an error
	     message and ask you to try again.	After you have
	     successfully logged in, _x_d_m will start up your X
	     environment.  By default, if you have an executable
	     file named ._x_s_e_s_s_i_o_n in your home directory, _x_d_m
	     will treat it as a program (or shell script) to run
	     to start up your initial clients (such as terminal
	     emulators, clocks, a window manager, user settings
	     for things like the background, the speed of the
	     pointer, etc.).  Your site administrator can provide
	     details.

     _x_i_n_i_t [1m(run manually from the shell)



[0mPrinted 25/2/93             Release 4				2






X(1)		    UNIX Programmer's Manual		     X(1)



	     Sites that support more than one window system might
	     choose to use the _x_i_n_i_t program for starting X manu-
	     ally.  If this is true for your machine, your site
	     administrator will probably have provided a program
	     named "x11", "startx", or "xstart" that will do
	     site-specific initialization (such as loading con-
	     venient default resources, running a window manager,
	     displaying a clock, and starting several terminal
	     emulators) in a nice way.	If not, you can build
	     such a script using the _x_i_n_i_t program.  This utility
	     simply runs one user-specified program to start the
	     server, runs another to start up any desired
	     clients, and then waits for either to finish.  Since
	     either or both of the user-specified programs may be
	     a shell script, this gives substantial flexibility
	     at the expense of a nice interface.  For this rea-
	     son, _x_i_n_i_t is not intended for end users.

[1mDISPLAY NAMES
     [0mFrom the user's perspective, every X server has a _d_i_s_p_l_a_y
     _n_a_m_e of the form:

		 _h_o_s_t_n_a_m_e:_d_i_s_p_l_a_y_n_u_m_b_e_r._s_c_r_e_e_n_n_u_m_b_e_r

     This information is used by the application to determine how
     it should connect to the server and which screen it should
     use by default (on displays with multiple monitors):

     _h_o_s_t_n_a_m_e
	     The _h_o_s_t_n_a_m_e specifies the name of the machine to
	     which the display is physically connected.  If the
	     hostname is not given, the most efficient way of
	     communicating to a server on the same machine will
	     be used.

     _d_i_s_p_l_a_y_n_u_m_b_e_r
	     The phrase "display" is usually used to refer to
	     collection of monitors that share a common keyboard
	     and pointer (mouse, tablet, etc.).  Most worksta-
	     tions tend to only have one keyboard, and therefore,
	     only one display.	Larger, multi-user systems, how-
	     ever, will frequently have several displays so that
	     more than one person can be doing graphics work at
	     once.  To avoid confusion, each display on a machine
	     is assigned a _d_i_s_p_l_a_y _n_u_m_b_e_r (beginning at 0) when
	     the X server for that display is started.	The
	     display number must always be given in a display
	     name.

     _s_c_r_e_e_n_n_u_m_b_e_r
	     Some displays share a single keyboard and pointer
	     among two or more monitors.  Since each monitor has



Printed 25/2/93             Release 4				3






X(1)		    UNIX Programmer's Manual		     X(1)



	     its own set of windows, each screen is assigned a
	     _s_c_r_e_e_n _n_u_m_b_e_r (beginning at 0) when the X server for
	     that display is started.  If the screen number is
	     not given, then screen 0 will be used.

     On POSIX systems, the default display name is stored in your
     DISPLAY environment variable.  This variable is set automat-
     ically by the _x_t_e_r_m terminal emulator.  However, when you
     log into another machine on a network, you'll need to set
     DISPLAY by hand to point to your display.	For example,

	     % setenv DISPLAY myws:0
	     $ DISPLAY=myws:0; export DISPLAY

     Finally, most X programs accept a command line option of
     [1m-display [0m_d_i_s_p_l_a_y_n_a_m_e to temporarily override the contents of
     DISPLAY.  This is most commonly used to pop windows on
     another person's screen or as part of a "remote shell" com-
     mand to start an xterm pointing back to your display.  For
     example,

	     % xeyes -display joesws:0 -geometry 1000x1000+0+0
	     % rsh big xterm -display myws:0 -ls </dev/null &

     X servers listen for connections on a variety of different
     communications channels (network byte streams, shared
     memory, etc.).  Since there can be more than one way of con-
     tacting a given server, The _h_o_s_t_n_a_m_e part of the display
     name is used to determine the type of channel (also called a
     transport layer) to be used.  The sample servers from MIT
     support the following types of connections:

     _l_o_c_a_l
	     The hostname part of the display name should be the
	     empty string.  For example:  :_0, :_1, and :_0._1.  The
	     most efficient local transport will be chosen.

     _T_C_P/_I_P
	     The hostname part of the display name should be the
	     server machine's IP address name.	Full Internet
	     names, abbreviated names, and IP addresses are all
	     allowed.  For example:  _e_x_p_o._l_c_s._m_i_t._e_d_u:_0, _e_x_p_o:_0,
	     _1_8._3_0._0._2_1_2:_0, _b_i_g_m_a_c_h_i_n_e:_1, and _h_y_d_r_a:_0._1.

[1mACCESS CONTROL
     [0mThe sample server provides two types of access control:  an
     authorization protocol which provides a list of ``magic
     cookies'' clients can send to request access, and a list of
     hosts from which connections are always accepted.	_X_d_m ini-
     tializes magic cookies in the server, and also places them
     in a file accessible to the user.	Normally, the list of
     hosts from which connections are always accepted should be



Printed 25/2/93             Release 4				4






X(1)		    UNIX Programmer's Manual		     X(1)



     empty, so that only clients with are explicitly authorized
     can connect to the display.  When you add entries to the
     host list (with _x_h_o_s_t), the server no longer performs any
     authorization on connections from those machines.	Be care-
     ful with this.

     The file for authorization which both _x_d_m and _X_l_i_b use can
     be specified with the environment variable [1mXAUTHORITY[0m, and
     defaults to the file [1m.Xauthority [0min the home directory.  _X_d_m
     uses [1m$HOME/.Xauthority [0mand will create it or merge in
     authorization records if it already exists when a user logs
     in.

     To manage a collection of authorization files containing a
     collection of authorization records use _x_a_u_t_h.  This program
     allows you to extract records and insert them into other
     files.  Using this, you can send authorization to remote
     machines when you login.  As the files are machine-
     independent, you can also simply copy the files or use NFS
     to share them.  If you use several machines, and share a
     common home directory with NFS, then you never really have
     to worry about authorization files, the system should work
     correctly by default.  Note that magic cookies transmitted
     ``in the clear'' over NFS or using _f_t_p or _r_c_p can be
     ``stolen'' by a network eavesdropper, and as such may enable
     unauthorized access.  In many environments this level of
     security is not a concern, but if it is, you need to know
     the exact semantics of the particular magic cookie to know
     if this is actually a problem.

[1mGEOMETRY SPECIFICATIONS
     [0mOne of the advantages of using window systems instead of
     hardwired terminals is that applications don't have to be
     restricted to a particular size or location on the screen.
     Although the layout of windows on a display is controlled by
     the window manager that the user is running (described
     below), most X programs accept a command line argument of
     the form [1m-geometry [0m_W_I_D_T_H_x_H_E_I_G_H_T+_X_O_F_F+_Y_O_F_F (where _W_I_D_T_H,
     _H_E_I_G_H_T, _X_O_F_F, and _Y_O_F_F are numbers) for specifying a pre-
     ferred size and location for this application's main window.

     The _W_I_D_T_H and _H_E_I_G_H_T parts of the geometry specification are
     usually measured in either pixels or characters, depending
     on the application.  The _X_O_F_F and _Y_O_F_F parts are measured in
     pixels and are used to specify the distance of the window
     from the left or right and top and bottom edges of the
     screen, respectively.  Both types of offsets are measured
     from the indicated edge of the screen to the corresponding
     edge of the window.  The X offset may be specified in the
     following ways:

     +_X_O_F_F   The left edge of the window is to be placed _X_O_F_F



Printed 25/2/93             Release 4				5






X(1)		    UNIX Programmer's Manual		     X(1)



	     pixels in from the left edge of the screen (i.e. the
	     X coordinate of the window's origin will be _X_O_F_F).
	     _X_O_F_F may be negative, in which case the window's
	     left edge will be off the screen.

     -_X_O_F_F   The right edge of the window is to be placed _X_O_F_F
	     pixels in from the right edge of the screen.  _X_O_F_F
	     may be negative, in which case the window's right
	     edge will be off the screen.

     The Y offset has similar meanings:

     +_Y_O_F_F   The top edge of the window is to be _Y_O_F_F pixels
	     below the top edge of the screen (i.e. the Y coordi-
	     nate of the window's origin will be _Y_O_F_F).  _Y_O_F_F may
	     be negative, in which case the window's top edge
	     will be off the screen.

     -_Y_O_F_F   The bottom edge of the window is to be _Y_O_F_F pixels
	     above the bottom edge of the screen.  _Y_O_F_F may be
	     negative, in which case the window's bottom edge
	     will be off the screen.

     Offsets must be given as pairs; in other words, in order to
     specify either _X_O_F_F or _Y_O_F_F both must be present.	The
     geometry specificaton must be correctly formed; some appli-
     cations will output a warning message (for example if [1mX [0mis
     used instead of [1mx[0m) others do not.	Windows can be placed in
     the four corners of the screen using the following specifi-
     cations:

     +_0+_0    upper left hand corner.

     -_0+_0    upper right hand corner.

     -_0-_0    lower right hand corner.

     +_0-_0    lower left hand corner.

     In the following examples, a terminal emulator will be
     placed in roughly the center of the screen and a load aver-
     age monitor, mailbox, and clock will be placed in the upper
     right hand corner:

	     xterm -fn 6x10 -geometry 80x24+30+200 &
	     xclock -geometry 48x48-0+0 &
	     xload -geometry 48x48-96+0 &
	     xbiff -geometry 48x48-48+0 &

[1mWINDOW MANAGERS
     [0mThe layout of windows on the screen is controlled by special
     programs called _w_i_n_d_o_w _m_a_n_a_g_e_r_s.  Although many window



Printed 25/2/93             Release 4				6






X(1)		    UNIX Programmer's Manual		     X(1)



     managers will honor geometry specifications as given, others
     may choose to ignore them (requiring the user to explicitly
     draw the window's region on the screen with the pointer, for
     example).

     Since window managers are regular (albeit complex) client
     programs, a variety of different user interfaces can be
     built.  The core distribution comes with a window manager
     named _t_w_m which supports overlapping windows, popup menus,
     point-and-click or click-to-type input models, title bars,
     nice icons (and an icon manager for those who don't like
     separate icon windows).

     Several other window managers are available in the user-
     contributed software: _g_w_m, _m__s_w_m, _o_l_w_m, and _t_e_k_w_m.

[1mFONT NAMES
     [0mCollections of characters for displaying text and symbols in
     X are known as _f_o_n_t_s.  A font typically contains images that
     share a common appearance and look nice together (for exam-
     ple, a single size, boldness, slant, and character set).
     Similarly, collections of fonts that are based on a common
     type face (the variations are usually called roman, bold,
     italic, bold italic, oblique, and bold oblique) are called
     _f_a_m_i_l_i_e_s.

     Sets of font families of the same resolution (usually meas-
     ured in dots per inch) are further grouped into _d_i_r_e_c_t_o_r_i_e_s
     (so named because they were initially stored in file system
     directories).  Each directory contains a database which
     lists the name of the font and information on how to find
     the font.	The server uses these databases to translate _f_o_n_t
     _n_a_m_e_s (which have nothing to do with file names) into font
     data.

     The list of font directories in which the server looks when
     trying to find a font is controlled by the _f_o_n_t _p_a_t_h.
     Although most installations will choose to have the server
     start up with all of the commonly used font directories, the
     font path can be changed at any time with the _x_s_e_t program.
     However, it is important to remember that the directory
     names are on the [1mserver[0m's machine, not on the application's.

     The default font path for the sample server contains three
     directories:

     /_u_s_r/_l_i_b/_X_1_1/_f_o_n_t_s/_m_i_s_c
	     This directory contains many miscellaneous fonts
	     that are useful on all systems.  It contains a small
	     family of fixed-width fonts in pixel heights 5
	     through 10, a family of fixed-width fonts from Dale
	     Schumacher in similar pixel heights, several Kana



Printed 25/2/93             Release 4				7






X(1)		    UNIX Programmer's Manual		     X(1)



	     fonts from Sony Corporation, a Kanji font, the stan-
	     dard cursor font, two cursor fonts from Digital
	     Equipment Corporation, and OPEN LOOK(tm) cursor and
	     glyph fonts from Sun Microsystems.  It also has font
	     name aliases for the font names [1mfixed [0mand [1mvariable[0m.

     /_u_s_r/_l_i_b/_X_1_1/_f_o_n_t_s/_7_5_d_p_i
	     This directory contains fonts contributed by Adobe
	     Systems, Inc., Digital Equipment Corporation,
	     Bitstream, Inc., Bigelow and Holmes, and Sun
	     Microsystems, Inc.  for 75 dots per inch displays.
	     An integrated selection of sizes, styles, and
	     weights are provided for each family.

     /_u_s_r/_l_i_b/_X_1_1/_f_o_n_t_s/_1_0_0_d_p_i
	     This directory contains 100 dots per inch versions
	     of some of the fonts in the _7_5_d_p_i directory.

     Font databases are created by running the _m_k_f_o_n_t_d_i_r program
     in the directory containing the source or compiled versions
     of the fonts (in both compressed and uncompressed formats).
     Whenever fonts are added to a directory, _m_k_f_o_n_t_d_i_r should be
     rerun so that the server can find the new fonts.  To make
     the server reread the font database, reset the font path
     with the _x_s_e_t program.  For example, to add a font to a
     private directory, the following commands could be used:

	     %	cp newfont.snf ~/myfonts
	     %	mkfontdir ~/myfonts
	     %	xset fp rehash

     The _x_l_s_f_o_n_t_s program can be used to list all of the fonts
     that are found in font databases in the current font path.
     Font names tend to be fairly long as they contain all of the
     information needed to uniquely identify individual fonts.
     However, the sample server supports wildcarding of font
     names, so the full specification

     -_a_d_o_b_e-_c_o_u_r_i_e_r-_m_e_d_i_u_m-_r-_n_o_r_m_a_l--_1_0-_1_0_0-_7_5-_7_5-_m-_6_0-_i_s_o_8_8_5_9-_1

     could be abbreviated as:

	    -*-_c_o_u_r_i_e_r-_m_e_d_i_u_m-_r-_n_o_r_m_a_l--*-_1_0_0-*-*-*-*-*-*

     or, more tersely (but less accurately):

		  *-_c_o_u_r_i_e_r-_m_e_d_i_u_m-_r-_n_o_r_m_a_l--*-_1_0_0-*

     Because the shell also has special meanings for * and ?,
     wildcarded font names should be quoted:

	     %	xlsfonts -fn '*-courier-medium-r-normal--*-100-*'



Printed 25/2/93             Release 4				8






X(1)		    UNIX Programmer's Manual		     X(1)



     If more than one font in a given directory in the font path
     matches a wildcarded font name, the choice of which particu-
     lar font to return is left to the server.	However, if fonts
     from more than one directory match a name, the returned font
     will always be from the first such directory in the font
     path.  The example given above will match fonts in both the
     _7_5_d_p_i and _1_0_0_d_p_i directories; if the _7_5_d_p_i directory is
     ahead of the _1_0_0_d_p_i directory in the font path, the smaller
     version of the font will be used.

[1mCOLOR NAMES
     [0mMost applications provide ways of tailoring (usually through
     resources or command line arguments) the colors of various
     elements in the text and graphics they display.  Although
     black and white displays don't provide much of a choice,
     color displays frequently allow anywhere between 16 and 16
     million different colors.

     Colors are usually specified by their commonly-used names
     (for example, _r_e_d, _w_h_i_t_e, or _m_e_d_i_u_m _s_l_a_t_e _b_l_u_e).  The server
     translates these names into appropriate screen colors using
     a color database that can usually be found in
     /_u_s_r/_l_i_b/_X_1_1/_r_g_b._t_x_t.  Color names are case-insensitive,
     meaning that _r_e_d, _R_e_d, and _R_E_D all refer to the same color.

     Many applications also accept color specifications of the
     following form:

				 #rgb
			       #rrggbb
			      #rrrgggbbb
			    #rrrrggggbbbb

     where _r, _g, and _b are hexadecimal numbers indicating how
     much _r_e_d, _g_r_e_e_n, and _b_l_u_e should be displayed (zero being
     none and ffff being on full).  Each field in the specifica-
     tion must have the same number of digits (e.g., #rrgb or
     #gbb are not allowed).  Fields that have fewer than four
     digits (e.g. #rgb) are padded out with zero's following each
     digit (e.g. #r000g000b000).  The eight primary colors can be
     represented as:

	     black	 #000000000000 (no color at all)
	     red	 #ffff00000000
	     green	 #0000ffff0000
	     blue	 #00000000ffff
	     yellow	 #ffffffff0000 (full red and green, no blue)
	     magenta	 #ffff0000ffff
	     cyan	 #0000ffffffff
	     white	 #ffffffffffff (full red, green, and blue)





Printed 25/2/93             Release 4				9






X(1)		    UNIX Programmer's Manual		     X(1)



     Unfortunately, RGB color specifications are highly unport-
     able since different monitors produce different shades when
     given the same inputs.  Similarly, color names aren't port-
     able because there is no standard naming scheme and because
     the color database needs to be tuned for each monitor.

     Application developers should take care to make their colors
     tailorable.

[1mKEYS
     [0mThe X keyboard model is broken into two layers:  server-
     specific codes (called _k_e_y_c_o_d_e_s) which represent the physi-
     cal keys, and server-independent symbols (called _k_e_y_s_y_m_s)
     which represent the letters or words that appear on the
     keys. Two tables are kept in the server for converting key-
     codes to keysyms:

     _m_o_d_i_f_i_e_r _l_i_s_t
	     Some keys (such as Shift, Control, and Caps Lock)
	     are known as _m_o_d_i_f_i_e_r and are used to select dif-
	     ferent symbols that are attached to a single key
	     (such as Shift-a generates a capital A, and
	     Control-l generates a formfeed character ^L).  The
	     server keeps a list of keycodes corresponding to the
	     various modifier keys.  Whenever a key is pressed or
	     released, the server generates an _e_v_e_n_t that con-
	     tains the keycode of the indicated key as well as a
	     mask that specifies which of the modifier keys are
	     currently pressed.  Most servers set up this list to
	     initially contain the various shift, control, and
	     shift lock keys on the keyboard.

     _k_e_y_m_a_p _t_a_b_l_e
	     Applications translate event keycodes and modifier
	     masks into keysyms using a _k_e_y_s_y_m _t_a_b_l_e which con-
	     tains one row for each keycode and one column for
	     various modifier states.  This table is initialized
	     by the server to correspond to normal typewriter
	     conventions, but is only used by client programs.

     Although most programs deal with keysyms directly (such as
     those written with the X Toolkit Intrinsics), most program-
     ming libraries provide routines for converting keysyms into
     the appropriate type of string (such as ISO Latin-1).

[1mOPTIONS
     [0mMost X programs attempt to use the same names for command
     line options and arguments.  All applications written with
     the X Toolkit Intrinsics automatically accept the following
     options:

     [1m-display [0m_d_i_s_p_l_a_y



Printed 25/2/93             Release 4			       10






X(1)		    UNIX Programmer's Manual		     X(1)



	     This option specifies the name of the X server to
	     use.

     [1m-geometry [0m_g_e_o_m_e_t_r_y
	     This option specifies the initial size and location
	     of the window.  See the section on [1mGEOMETRY SPECIFI-
	     CATIONS [0mabove.

     [1m-bg [0m_c_o_l_o_r[1m, -background [0m_c_o_l_o_r
	     Either option specifies the color to use for the
	     window background.

     [1m-bd [0m_c_o_l_o_r[1m, -bordercolor [0m_c_o_l_o_r
	     Either option specifies the color to use for the
	     window border.  Window managers which provide their
	     own borders for client windows may cause this option
	     to be ignored.

     [1m-bw [0m_n_u_m_b_e_r[1m, -borderwidth [0m_n_u_m_b_e_r
	     Either option specifies the width in pixels of the
	     window border.  Window managers which provide their
	     own borders for client windows may cause this option
	     to be ignored.

     [1m-fg [0m_c_o_l_o_r[1m, -foreground [0m_c_o_l_o_r
	     Either option specifies the color to use for text or
	     graphics.

     [1m-fn [0m_f_o_n_t[1m, -font [0m_f_o_n_t
	     Either option specifies the font to use for display-
	     ing text.

     [1m-iconic
	     [0mThis option indicates that the user would prefer
	     that the application's windows initially not be
	     visible as if the windows had be immediately iconi-
	     fied by the user.	Window managers may choose not to
	     honor the application's request.

     [1m-name
	     [0mThis option specifies the name under which resources
	     for the application should be found.  This option is
	     useful in shell aliases to distinguish between invo-
	     cations of an application, without resorting to
	     creating links to alter the executable file name.

     [1m-rv[0m, [1m-reverse
	     [0mEither option indicates that the program should
	     simulate reverse video if possible, often by swap-
	     ping the foreground and background colors.  Not all
	     programs honor this or implement it correctly.  It
	     is usually only used on monochrome displays.



Printed 25/2/93             Release 4			       11






X(1)		    UNIX Programmer's Manual		     X(1)



     [1m+rv
	     [0mThis option indicates that the program should not
	     simulate reverse video. This is used to override any
	     defaults since reverse video doesn't always work
	     properly.

     [1m-selectionTimeout
	     [0mThis option specifies the timeout in milliseconds
	     within which two communicating applications must
	     respond to one another for a selection request.

     [1m-synchronous
	     [0mThis option indicates that requests to the X server
	     should be sent synchronously, instead of asynchro-
	     nously.  Since _X_l_i_b normally buffers requests to the
	     server, errors do not necessarily get reported
	     immediately after they occur.  This option turns off
	     the buffering so that the application can be
	     debugged.	It should never be used with a working
	     program.

     [1m-title [0m_s_t_r_i_n_g
	     This option specifies the title to be used for this
	     window.  This information is sometimes used by a
	     window manager to provide some sort of header iden-
	     tifying the window.

     [1m-xnllanguage [0m_l_a_n_g_u_a_g_e[__t_e_r_r_i_t_o_r_y][._c_o_d_e_s_e_t]
	     This option specifies the language, territory, and
	     codeset for use in resolving resource and other
	     filenames.

     [1m-xrm [0m_r_e_s_o_u_r_c_e_s_t_r_i_n_g
	     This option specifies a resource name and value to
	     override any defaults.  It is also very useful for
	     setting resources that don't have explicit command
	     line arguments.

[1mRESOURCES
     [0mTo make the tailoring of applications to personal prefer-
     ences easier, X supports several mechanisms for storing
     default values for program resources (e.g. background color,
     window title, etc.) Resources are specified as strings of
     the form

		 _a_p_p_n_a_m_e*_s_u_b_n_a_m_e*_s_u_b_s_u_b_n_a_m_e...: _v_a_l_u_e

     that are read in from various places when an application is
     run.  By convention, the application name is the same as the
     program name, but with the first letter capitalized (e.g.
     _B_i_t_m_a_p or _E_m_a_c_s) although some programs that begin with the
     letter ``x'' also capitalize the second letter for



Printed 25/2/93             Release 4			       12






X(1)		    UNIX Programmer's Manual		     X(1)



     historical reasons.  The precise syntax for resources is:

     ResourceLine   = Comment | ResourceSpec
     Comment	    = "!" string | <empty line>
     ResourceSpec   = WhiteSpace ResourceName WhiteSpace ":" WhiteSpace value
     ResourceName   = [Binding] ComponentName {Binding ComponentName}
     Binding	    = "." | "*"
     WhiteSpace     = {" " | "\t"}
     ComponentName  = {"a"-"z" | "A"-"Z" | "0"-"9" | "_" | "-"}
     value	    = string
     string	    = {<any character not including "\n">}

     Note that elements enclosed in curly braces ({...}) indicate
     zero or more occurrences of the enclosed elements

     To allow values to contain arbitrary octets, the 4-character
     sequence \_n_n_n, where n is a digit in the range of "0"-"7",
     is recognized and replaced with a single byte that contains
     this sequence interpreted as an octal number.  For example,
     a value containing a NULL byte can be stored by specifying
     "\000".

     The _X_l_i_b routine _X_G_e_t_D_e_f_a_u_l_t(_3_X) and the resource utilities
     within Xlib and the X Toolkit Intrinsics obtain resources
     from the following sources:

     [1mRESOURCE_MANAGER root window property
	     [0mAny global resources that should be available to
	     clients on all machines should be stored in the
	     RESOURCE_MANAGER property on the root window using
	     the _x_r_d_b program.	This is frequently taken care of
	     when the user starts up X through the display
	     manager or _x_i_n_i_t.

     [1mapplication-specific files
	     [0mPrograms that use the X Toolkit Intrinsics will also
	     look in the directories named by the environment
	     variable XUSERFILESEARCHPATH or the environment
	     variable XAPPLRESDIR, plus directories in a standard
	     place (usually under /usr/lib/X11/, but this can be
	     overridden with the XFILESEARCHPATH environment
	     variable) for application-specific resources.  See
	     the _X _T_o_o_l_k_i_t _I_n_t_r_i_n_s_i_c_s - _C _L_a_n_g_u_a_g_e _I_n_t_e_r_f_a_c_e
	     manual for details.

     [1mXENVIRONMENT
	     [0mAny user- and machine-specific resources may be
	     specified by setting the XENVIRONMENT environment
	     variable to the name of a resource file to be loaded
	     by all applications.  If this variable is not
	     defined, a file named $_H_O_M_E/.Xdefaults-_h_o_s_t_n_a_m_e is
	     looked for instead, where _h_o_s_t_n_a_m_e is the name of



Printed 25/2/93             Release 4			       13






X(1)		    UNIX Programmer's Manual		     X(1)



	     the host where the application is executing.

     [1m-xrm [0m_r_e_s_o_u_r_c_e_s_t_r_i_n_g
	     Applications that use the X Toolkit Intrinsics can
	     have resources specified from the command line.  The
	     _r_e_s_o_u_r_c_e_s_t_r_i_n_g is a single resource name and value
	     as shown above.  Note that if the string contains
	     characters interpreted by the shell (e.g., aster-
	     isk), they must be quoted.  Any number of [1m-xrm [0margu-
	     ments may be given on the command line.

     Program resources are organized into groups called _c_l_a_s_s_e_s,
     so that collections of individual resources (each of which
     are called _i_n_s_t_a_n_c_e_s) can be set all at once.  By conven-
     tion, the instance name of a resource begins with a lower-
     case letter and class name with an upper case letter.  Mul-
     tiple word resources are concatenated with the first letter
     of the succeeding words capitalized.  Applications written
     with the X Toolkit Intrinsics will have at least the follow-
     ing resources:

     [1mbackground ([0mclass [1mBackground)
	     [0mThis resource specifies the color to use for the
	     window background.

     [1mborderWidth ([0mclass [1mBorderWidth)
	     [0mThis resource specifies the width in pixels of the
	     window border.

     [1mborderColor ([0mclass [1mBorderColor)
	     [0mThis resource specifies the color to use for the
	     window border.

     Most applications using the X Toolkit Intrinsics also have
     the resource [1mforeground [0m(class [1mForeground[0m), specifying the
     color to use for text and graphics within the window.

     By combining class and instance specifications, application
     preferences can be set quickly and easily.  Users of color
     displays will frequently want to set Background and Fore-
     ground classes to particular defaults.  Specific color
     instances such as text cursors can then be overridden
     without having to define all of the related resources.  For
     example,

	     bitmap*Dashed:  off
	     XTerm*cursorColor:  gold
	     XTerm*multiScroll:  on
	     XTerm*jumpScroll:	on
	     XTerm*reverseWrap:  on
	     XTerm*curses:  on
	     XTerm*Font:  6x10



Printed 25/2/93             Release 4			       14






X(1)		    UNIX Programmer's Manual		     X(1)



	     XTerm*scrollBar: on
	     XTerm*scrollbar*thickness: 5
	     XTerm*multiClickTime: 500
	     XTerm*charClass:  33:48,37:48,45-47:48,64:48
	     XTerm*cutNewline: off
	     XTerm*cutToBeginningOfLine: off
	     XTerm*titeInhibit:  on
	     XTerm*ttyModes:  intr ^c erase ^? kill ^u
	     XLoad*Background: gold
	     XLoad*Foreground: red
	     XLoad*highlight: black
	     XLoad*borderWidth: 0
	     emacs*Geometry:  80x65-0-0
	     emacs*Background:	#5b7686
	     emacs*Foreground:	white
	     emacs*Cursor:  white
	     emacs*BorderColor:  white
	     emacs*Font:  6x10
	     xmag*geometry: -0-0
	     xmag*borderColor:	white

     If these resources were stored in a file called ._X_r_e_s_o_u_r_c_e_s
     in your home directory, they could be added to any existing
     resources in the server with the following command:

	     %	xrdb -merge $HOME/.Xresources

     This is frequently how user-friendly startup scripts merge
     user-specific defaults into any site-wide defaults.  All
     sites are encouraged to set up convenient ways of automati-
     cally loading resources. See the _X_l_i_b manual section _U_s_i_n_g
     _t_h_e _R_e_s_o_u_r_c_e _M_a_n_a_g_e_r for more information.

[1mEXAMPLES
     [0mThe following is a collection of sample command lines for
     some of the more frequently used commands.  For more infor-
     mation on a particular command, please refer to that
     command's manual page.

	     %	xrdb -load $HOME/.Xresources
	     %	xmodmap -e "keysym BackSpace = Delete"
	     %	mkfontdir /usr/local/lib/X11/otherfonts
	     %	xset fp+ /usr/local/lib/X11/otherfonts
	     %	xmodmap $HOME/.keymap.km
	     %	xsetroot -solid '#888'
	     %	xset b 100 400 c 50 s 1800 r on
	     %	xset q
	     %	twm
	     %	xmag
	     %	xclock -geometry 48x48-0+0 -bg blue -fg white
	     %	xeyes -geometry 48x48-48+0
	     %	xbiff -update 20



Printed 25/2/93             Release 4			       15






X(1)		    UNIX Programmer's Manual		     X(1)



	     %	xlsfonts '*helvetica*'
	     %	xlswins -l
	     %	xwininfo -root
	     %	xdpyinfo -display joesworkstation:0
	     %	xhost -joesworkstation
	     %	xrefresh
	     %	xwd | xwud
	     %	bitmap companylogo.bm 32x32
	     %	xcalc -bg blue -fg magenta
	     %	xterm -geometry 80x66-0-0 -name myxterm $*

[1mDIAGNOSTICS
     [0mA wide variety of error messages are generated from various
     programs.	Various toolkits are encouraged to provide a com-
     mon mechanism for locating error text so that applications
     can be tailored easily.  Programs written to interface
     directly to the _X_l_i_b C language library are expected to do
     their own error checking.

     The default error handler in _X_l_i_b (also used by many toolk-
     its) uses standard resources to construct diagnostic mes-
     sages when errors occur.  The defaults for these messages
     are usually stored in /_u_s_r/_l_i_b/_X_1_1/_X_E_r_r_o_r_D_B.  If this file
     is not present, error messages will be rather terse and
     cryptic.

     When the X Toolkit Intrinsics encounter errors converting
     resource strings to the appropriate internal format, no
     error messages are usually printed.  This is convenient when
     it is desirable to have one set of resources across a
     variety of displays (e.g. color vs. monochrome, lots of
     fonts vs. very few, etc.), although it can pose problems for
     trying to determine why an application might be failing.
     This behavior can be overridden by the setting the
     _S_t_r_i_n_g_C_o_n_v_e_r_s_i_o_n_s_W_a_r_n_i_n_g resource.

     To force the X Toolkit Intrinsics to always print string
     conversion error messages, the following resource should be
     placed at the top of the file that gets loaded onto the
     RESOURCE_MANAGER property using the _x_r_d_b program (frequently
     called ._X_r_e_s_o_u_r_c_e_s or ._X_r_e_s in the user's home directory):

	     *StringConversionWarnings: on

     To have conversion messages printed for just a particular
     application, the appropriate instance name can be placed
     before the asterisk:

	     xterm*StringConversionWarnings: on

[1mBUGS
     [0mIf you encounter a [1mrepeatable [0mbug, please contact your site



Printed 25/2/93             Release 4			       16






X(1)		    UNIX Programmer's Manual		     X(1)



     administrator for instructions on how to submit an X Bug
     Report.

[1mSEE ALSO
     [0mXConsortium(1), XStandards(1), appres(1), bdftosnf(1), bit-
     map(1), imake(1), listres(1), maze(1), mkfontdir(1),
     muncher(1), oclock(1), puzzle(1), resize(1), showsnf(1),
     twm(1), xauth(1), xbiff(1), xcalc(1), xclipboard(1),
     xclock(1), xcontrol(1), xdm(1), xdpyinfo(1), xedit(1),
     xev(1), xeyes(1), xfd(1), xfontsel(1), xhost(1), xinit(1),
     xkill(1), xload(1), xlogo(1), xlsatoms(1), xlsclients(1),
     xlsfonts(1), xlswins(1), xmag(1), xman(1), xmail(1), xmod-
     map(1), xpr(1), xprop(1), xrdb(1), xrefresh(1), xset(1),
     xsetroot(1), xsm(1), xstdcmap(1), xterm(1), xwd(1),
     xwininfo(1), xwud(1), Xarm(1), Xserver(1), biff(1), init(8),
     ttys(5), _X_l_i_b - _C _L_a_n_g_u_a_g_e _X _I_n_t_e_r_f_a_c_e, _X _T_o_o_l_k_i_t _I_n_t_r_i_n_s_i_c_s
     - _C _L_a_n_g_u_a_g_e _I_n_t_e_r_f_a_c_e, and _U_s_i_n_g _a_n_d _S_p_e_c_i_f_y_i_n_g _X _R_e_s_o_u_r_c_e_s

[1mCOPYRIGHT
     [0mThe following copyright and permission notice outlines the
     rights and restrictions covering most parts of the core dis-
     tribution of the X Window System from MIT.  Other parts have
     additional or different copyrights and permissions; see the
     individual source files.

     Copyright 1984, 1985, 1986, 1987, 1988, and 1989, by the
     Massachusetts Institute of Technology.

     Permission to use, copy, modify, distribute, and sell this
     software and its documentation for any purpose is hereby
     granted without fee, provided that the above copyright
     notice appear in all copies and that both that copyright
     notice and this permission notice appear in supporting docu-
     mentation, and that the name of MIT not be used in advertis-
     ing or publicity pertaining to distribution of the software
     without specific, written prior permission.  MIT makes no
     representations about the suitability of this software for
     any purpose.  It is provided "as is" without express or
     implied warranty.

     This software is not subject to any license of the American
     Telephone and Telegraph Company or of the Regents of the
     University of California.

[1mTRADEMARKS
     [0mUNIX and OPEN LOOK are trademarks of AT&T.  X Window System
     is a trademark of MIT.

[1mAUTHORS
     [0mA cast of thousands, literally.  The X distribution is
     brought to you by the MIT X Consortium.  The staff members
     at MIT responsible for this release are: Donna Converse (MIT



Printed 25/2/93             Release 4			       17






X(1)		    UNIX Programmer's Manual		     X(1)



     X Consortium), Jim Fulton (MIT X Consortium), Michelle Leger
     (MIT X Consortium), Keith Packard (MIT X Consortium), Chris
     Peterson (MIT X Consortium), Bob Scheifler (MIT X Consor-
     tium), and Ralph Swick (Digital/MIT Project Athena).



















































Printed 25/2/93             Release 4			       18



[0m