OT What does RET (Enter) do and how does it do it ??

[William Case]

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