ARPUS/ce, Version 2.6.2 (03/10/05) (SCCS 1.5)
_______________________________________________________________________________
.Cekeys file
"Permanent Key defintions"
DESCRIPTION:
The .Cekeys file is normally created by the ce_init command prior to
the first time Ce is invoked. The ce_init command populates the file
with some standard key defintions and some key defintions tailored for
the platform it is being run on.
Former HP/Apollo Domain users may want to add in key defintions from
their ~/user_data/key_defintions file. The syntax of the definitions
is largely the same (In some key definitions the number of escape
characters is different). On non-Apollo platforms the names of the
keys change. The 'kk' command can be used to determine what key names
correspond to each physical key.
The .Cekeys file is a special cmdf file which can only contain
'kd' commands, 'wdf' commands, 'wdc' commands, and 'cmdf' commands.
The 'cmdf' commmands are supported as an include mechanism and may
only contain the previously listed commands.
Why only certain commands?
The contents of the .Cekeys file are read in and processed prior to
any windows being created. They are also read in only once, the first
time Ce is invoked. After that they are stored in an X resource in
the X server. There are two reasons for not allowing other commands
in the .Cekeys file. First, since the .Cekeys file is processed
before the window is created, a command such as 'ad' has no meaning
without a window to arrow down in. Second, the .Cekeys file is only
read in and executed once, so any commands would only get executed
once per login even if they were allowed. If there are a group of
commands which need to be executed every time a Ce window is brought
up, use the X resource Ce.cmd, ce.cmd, cv.cmd, or ceterm.cmd and
execute a cmdf of some command file to achieve the desired result.
It is quite common to execute the command "ce -load" in the .profile
or .xinitrc file. This preloads the Ce keys prior to the first window
being brought up. It also avoids a possible startup situation where
sereral windows are being brought up at one time and several of the
windows may read the .Cekeys because they started before the first one
posted that it had read the .Cekeys file. This should not cause a
problem other than a performance degradation during login. The -load
parameter causes Ce to check if the .Cekeys file has already been
loaded into the X server and exits immeditately if the definitions are
already loaded.
The command "ce -reload" can be used to force the .Cekeys file to be
read in again. The -reload parameter differs from the -load parameter
in that the key definitions in the X server are deleted prior to
begining to read the .Cekeys file in. The effect on running Ce
windows is to replace like keyed key defintions with the ones read in.
That is: A running Ce session will receive notification of the key
definition change and retrieve it from the X server replacing any
existing key definition for that key. A key defined in the running Ce
session which is not referenced in the .Cekeys file will not be
replaced.
Another reason for putting "ce -load" in the .profile or .xinitrc file
is to make sure the key definitions for the local work station are
read in. Ce reads in the key definitions in once and saves them in the
X server. Ce sessions started after the key definitions are loaded use
the preparsed copy in the server. This becomes important in a mixed
ventor environment. Suppose a user sitting on a Sun workstation
telnets to an HP workstation and starts a ceterm session displaying
back on the Sun he is sitting at. The home directory on the HP will
contain a .Cekeys file which maps wel to the HP keyboard, but would be
a dismal failure on the Sun keyboard. If the key definitions from the
Sun have already been loaded into the X server, the new ceterm will
use them and everything will work fine. Since the normal mode of
operation is to open one or more windows locally before telnet'ing to
another node, doing nothing will work fine. The thing to be avoided
is executing ce -reload in a telnet session. All your key definitions
will be replaced with the key defintions for the machine you are
telnet'ed to.
It is possible that a user will have a single home directory across
several hardware platforms. In this case several .Cekeys files are
necessary, one per keyboard. The environment variable CEKEYS allows
resolution of this problem. In the users .profile, tests can be made
using the uname(1) command or existence of certain files to determine
which hardware platform is being logged onto. The CEKEYS environment
variable can then be set to values such as CEKEYS=".Cekeys.sun" or
CEKEYS=".Cekeys.hp" and then exported.
NOTES:
1. In this discusson, Ce refers to ce, ceterm, and cv.
2. If a set of key defintions suddenly stop working, make sure the
caps lock or num lock keys are not active.
3. Do NOT run ce -reload when telneted to a dissimilar hardware platform.
4. If ce -reload seems to have no effect, check the environment variable
CEKEYS in the shell doing the ce -reload.
RELATED HELP FILES:
keyboard (Generic Keyboard)
keyCon (Key Concepts)
cmdf (Command File)
kd (Key Definition)
kk (Key Key)
wdf (Window Default Geo)
wdc (Window Default Color)
commands (List of Commands)
xresources (X resources & args)
support (customer support)
_______________________________________________________________________________
Copyright (c) 2005, Robert Styma Consulting. All rights reserved.