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.