Hi Tim; I think Rick Stevens cued in on the problem I was having. His point was so spot on that it is worth repeating, just to drive it into my head. On Sat, 2007-08-25 at 14:17 +0930, Tim wrote: > On Fri, 2007-08-24 at 17:42 But I have been > > having difficulty even explaining what I am asking. I usually get > > answers of the kind "Of course it executes the command. You pushed > > RET" > > What happens when you press a key depends on the listening program. > Pressing "A" doesn't always type an A to the screen, likewise ENTER > doesn't always do the same thing (accepts the entry of data, finishes a > paragraph, inserts a blank line, etc.). > > The terminal is an interface between keyboard and a program. That > program might be the BASH interpreter, it might be a text editor. > Unless the interface snaffles up a keypress for itself (e.g. F11 for > full screen, in Gnome Terminal), the keypress is passed onto the end > program, for it do what it does with it, and perhaps returning some > acknowledging display to the interface. You make much the same point Rick does. > That does demonstrate the problems of writing some programs - you may > have to design them for the limits of environments they're likely to be > used in (e.g. you couldn't expect always being able to notice the F11 > key being pressed, in your program). > > I've omitted at least one preceding part of the equation. When you > press a key on the keyboard, e.g. "S", you're pressing key three down, > two across on a QWERTY keyboard. It doesn't mean "S" to anything, at > this stage. There's a keymap that associates keys in certain positions > with certain labels. That means that all programs can use "S" as "S," > in documentation and programming, no matter what keyboard you have, else > you'd have programs that used different hotkeys depending on your > keyboard (e.g. the same key is an "O" on a Dvorak keyboard). I recall > Doten wishing that he could make his work differently, the other way > around, so that cut and paste, for instance, always used the same > buttons on the keyboard, no matter what letters they could represent-0400, William Case wrote: > > I suppose there is a simple answer; there should be. I was well aware of the transformation of scan codes on my keyboard to key codes and how key codes are translated by keymaps and the use of such programs as Xev and Xmodmap to trace these assignments. I could understand how a text writing program, for example, would define for its self through the use of keymaps what each key press might eventually mean. Rick says: "That's pretty much it in a nutshell. Generally, RET (ENTER) is used to signify the end of a line. What the program _does_ with that line is up to the program." This assignment of the RET (ENTER) to signifying a new line, ties in neatly with the meaning of a canonical mode although it is also applicable to a raw mode. "I was also trying to emphasize that command prompts are really another program (on *nix, the shell; on DOS/Windows, command.com or whatever Windows calls it now) asking for input." After receiving Rick's post, I went upstairs had a pop, watched some TV then came back to my computer and re-read Rick's paragraph quoted above. Then it dawned on me -- real honest to God eureka moment. The shell was waiting for input. I knew that the shell was the first program to run, that it was always running but I knew as a kind of learnt metaphysical thing. The reality of the always present shell didn't become concrete until I had re-read Rick's post. Up until then, a command prompt intuitively seemed like a raw virgin screen, on which nothing was yet happening, sitting there, cursor blinking, waiting for me to type in something and start a process. From that wrong intuitive assumption, it was easy to then ask myself "Well if I am starting with nothing happening, what makes the program I type in, go?" Of course, something is happening. The clear screen with just a program prompt is a program -- the shell, in my case Bash. That changes everything. RET(Enter) doesn't have to change or know context or anything like that. As long as some program (as basic as Bash or as sophisticated as Writer) is waiting for input; as long as the keycode is consistent, say a new line, but it could be anything; and as long as all programs were written to read that keycode when it was passed to the program, then the program could do whatever it was written to do with the RET keycode. Text programs could read that code as an instruction to insert new lines and do a carriage return; and executable programs could read the keycode as an instruction to execute the program. Sorry to take so much space feeding back what I have already been told; but it is a good opportunity to explain it back to myself and to hammer into a sometimes thick head a newly understood truth. The shell is always running/sleeping -- waiting for input. -- Regards Bill
