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.