On Fri, 2007-08-24 at 18:52 -0400, William Case wrote: > Thanks Rick; > > I put your answer together with Alan's and I think I get a satisfying > answer. > > On Fri, 2007-08-24 at 15:09 -0700, Rick Stevens wrote: > > On Fri, 2007-08-24 at 17:42 -0400, William Case wrote: > > > Hi; > > > > > > This question is meant as a Friday afternoon to a Sunday evening > > > discussion. It is not rush; but I have been unable to discover an answer > > > to what seems to me a basic question on how my computer works. > > > > > > > > > [snip] > > > Well, it's simple. The intent of text editors, word processors and the > > like is that whatever you type in gets saved in the file. In *nix-ish > > operating systems (Linux, Unix, MacOS, etc.), the RETURN or ENTER key is > > denoted by a single character in the file. We call this the "newline" > > character, which is the hexadecimal value 0x0a. In ASCII parlance, > > that's the "LF" or "linefeed" character. The LF character can also > > be entered by holding down the "CTRL" key and pressing "j" (also > > sometimes called "control-J"). > > > > In Windows-type stuff (DOS, Windows, CP/M, etc.), the ENTER key is > > denoted by a two character sequence, the hex value 0x0d (ASCII "CR" or > > "carriage return"), followed by the hex value 0x0a (ASCII "LF" or > > "linefeed" again). We call this sequence the "CRLF" sequence. Note > > that the "CR" character can also be entered by holding down the "CTRL" > > key and pressing "m", which is why it's sometimes called "control-M". > > > > (ADDITIONAL INFO: The hex value of "m" is "0x4d" and that of "j" is > > 0x4a. Holding down the CTRL key inhibits the generation of bit 6 or > > the value of 0x40, so CTRL-M generates 0x0d instead of 0x4d. Easy.) > > > > So much for text editors, word processors and the like. Now, when > > you're at a command prompt or other program requesting input (remember > > that the command prompt is the shell program asking for input), the > > RETURN (or ENTER) key signals the end of user input and the program then > > processes that according to whatever the program is supposed to do. > > > > Does that clarify things? > > > To re-summarize, the meaning of RET is established by the program being > used. The program can create it's own meaning for RET; or use a > standardized meaning according to what has been bound to the keymap the > program is using, or redefine the keymap it uses to bind one or another > meaning to a key press or event. programs come in two types in terms of events. One and most common form is to simply have an if-then-else structure such that the event travels down the if tree and branches at the place it finds a true condition based upon the logic: if (keychar==0x0a) dosomething; else if (keychar==0x0b) do something; A more recent form is that of an event processing process. The os can use a keymap to generate events and those events can be of multiple types. Thus an event such as pressing the return key could present the software with two events: a keypress and/or a RET event. In this case the program would then implement an event handler. The event handler would only fire if the program's parent had the focus (was the window you were working in). Thus both events would be generated, but only the focused window would take action. This is the model for Java for example, or for some complex multithreaded systems (which unix implements if you set it up that way), and in some cases, the parent window system operates in the "if else" mode, but dispatches events to the child processes. I realize this is difficult to grasp, but a keymap is an os concept, and basically is a piece of software that fits between the driver for the keyboard and the OS, such that pressing a key will pass a code to the keymap, which looks at an array of logic, containing the key codes to translate, the code to output, and if necessary a bit of binary code to call to create an action. A key logger works in this fashion also, but the bit of code it executes writes the key strokes to a file which is the log of keystrokes. Regards, Les H
