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.
I have asked on my local LUG mailing list (which is usually quite good); searched the following text books; "Modern Operating Systems", 2nd ed, Andrew S. Tanenbaum; "Computer Organization & Architecture", 6th ed, William Stallings; "The Linux Kernel Primer", Rodriguez, Fischer, Smolski. I have done the usual google and Wikipedia. I mention the above to indicate I am am willing to dig quite deeply for an answer.
Since I have been unable to find an answer, I might be able to conclude I have mis-posed the question. That is why I am asking for your help, pointing me to the correct answer or offering me enough of an explanation, that I can begin to look in the right places.
Put simply: 1) If I am in any kind of text application, from emacs, vim to OOo Writer, whenever I push RET the line of characters I have just typed gets saved as a string literal the, "\n", new line character gets added to the string array, and the cursor gets moved down to the beginning of the next line. Of course, in the right circumstances within an application (i.e. menu selection) push RET to get a sub-program or a program module to run. (More questions in a moment)
2) If I am in a terminal at the command prompt and I type in a command, whenever I push RET the command name I just typed gets executed. When it is finished being executed I get a new command line prompt. Of course, a executed program can take a string as an argument.
For 1) How does the context (i.e. that I am in a text program) get established? Is there a context line at the start of the application? Is it through main(argc, argv) or some such, depending on the programming language of the application? How does it know to move one line down on the screen i.e. is there a system call, a special function ?
For 2) Again, how does the context (i.e. that I am in a terminal with a command prompt) get established? Is there an exec() call or system call to execute the program on pushing RET? How can stdin tell the difference? Why does exec(), or its brethren (fork() etc), act one way in one instance and another in the next instance? What is the command that RET issues that starts, forks, calls or whatever a process or program?
I suppose there is a simple answer; there should be. 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"
As I said, maybe I am mis-posing the question. Maybe someone could help me straighten the question out. Maybe someone can point me to an answer. It can't be a new question.
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.
I have asked on my local LUG mailing list (which is usually quite good); searched the following text books; "Modern Operating Systems", 2nd ed, Andrew S. Tanenbaum; "Computer Organization & Architecture", 6th ed, William Stallings; "The Linux Kernel Primer", Rodriguez, Fischer, Smolski. I have done the usual google and Wikipedia. I mention the above to indicate I am am willing to dig quite deeply for an answer.
Since I have been unable to find an answer, I might be able to conclude I have mis-posed the question. That is why I am asking for your help, pointing me to the correct answer or offering me enough of an explanation, that I can begin to look in the right places.
Put simply:
- If I am in any kind of text application, from emacs, vim to OOo
Writer, whenever I push RET the line of characters I have just typed gets saved as a string literal the, "\n", new line character gets added to the string array, and the cursor gets moved down to the beginning of the next line. Of course, in the right circumstances within an application (i.e. menu selection) push RET to get a sub-program or a program module to run. (More questions in a moment)
- If I am in a terminal at the command prompt and I type in a command,
whenever I push RET the command name I just typed gets executed. When it is finished being executed I get a new command line prompt. Of course, a executed program can take a string as an argument.
For 1) How does the context (i.e. that I am in a text program) get established? Is there a context line at the start of the application? Is it through main(argc, argv) or some such, depending on the programming language of the application? How does it know to move one line down on the screen i.e. is there a system call, a special function ?
For 2) Again, how does the context (i.e. that I am in a terminal with a command prompt) get established? Is there an exec() call or system call to execute the program on pushing RET? How can stdin tell the difference? Why does exec(), or its brethren (fork() etc), act one way in one instance and another in the next instance? What is the command that RET issues that starts, forks, calls or whatever a process or program?
I suppose there is a simple answer; there should be. 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"
As I said, maybe I am mis-posing the question. Maybe someone could help me straighten the question out. Maybe someone can point me to an answer. It can't be a new question.
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?
---------------------------------------------------------------------- - Rick Stevens, Principal Engineer rstevens@internap.com - - CDN Systems, Internap, Inc. http://www.internap.com - - - - Do you know how to save five drowning lawyers? No? GOOD! - ----------------------------------------------------------------------
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.
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.
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.
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.
---------------------------------------------------------------------- - Rick Stevens, Principal Engineer rstevens@internap.com - - CDN Systems, Internap, Inc. http://www.internap.com - - - - Silence! Or I shall replace you with a very small shell script! - - - The Wizard of OS - ----------------------------------------------------------------------
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
Thanks Les;
Don't be offended by the [Big Snip] -- just trying to keep the size down.
[Big Snip]
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.
No. Actually, it is not hard to grasp once someone lays it out for you.
If I may diverge for a moment. I have found there is a lot of information out there for "newbies" and a lot of exchanges of information for "gurus". But there is not much for those who have passed the newbie stage, but aren't yet ready to communicate with the gurus. People who you might call "newrus" or "gurbies". I hope that this question was something that fit that category.
I am not going to burden people's patience with new questions of this type at the moment, but I do have a file entitled "Really Basic Computer and Linux" which I keep adding to, and removing from when I get answers. Most often I come across those answers serendipitously so they are never publicly asked.
What I would now like ask is, is someone saving, arranging, compiling, harvesting these middle level answers so they can easily be found by the newrus and gurbies of the world? I know how long I have spent searching for answers or explanations.
Honestly, this latest exchange of information, learning, is a treasure trove of stuff that shouldn't be lost.
William Case wrote:
What I would now like ask is, is someone saving, arranging, compiling, harvesting these middle level answers so they can easily be found by the newrus and gurbies of the world? I know how long I have spent searching for answers or explanations.
You should consider starting a blog or making an FAQ about these questions.
Matt Flaschen
On Sat, 2007-08-25 at 14:15 -0400, Matthew Flaschen wrote:
William Case wrote:
What I would now like ask is, is someone saving, arranging, compiling, harvesting these middle level answers so they can easily be found by the newrus and gurbies of the world? I know how long I have spent searching for answers or explanations.
You should consider starting a blog or making an FAQ about these questions.
Maybe this would be a good Wiki. I mean from what I gather a wiki is about gathering and archiving knowledge from diverse sources?
Regards, Les H
On Sun, 2007-08-26 at 10:03 -0700, Les wrote:
On Sat, 2007-08-25 at 14:15 -0400, Matthew Flaschen wrote:
William Case wrote:
What I would now like ask is, is someone saving, arranging, compiling, harvesting these middle level answers so they can easily be found by the newrus and gurbies of the world? I know how long I have spent searching for answers or explanations.
You should consider starting a blog or making an FAQ about these questions.
Maybe this would be a good Wiki. I mean from what I gather a wiki is about gatherW Regards, Les H
Well that is an idea. Just getting across that each key generates a keycode and what the programs do with the keycodes is up to the programs.
A second basic fact that needs to be undertood, which OP I think did not, is that what comes out of the keyboard or any other input device is just a stream of characters read from the appropriate buffer. What a program like vi does with that stream may make it look like a series of lines across the width of the window but that is an artifact of what vi does with the character stream it receives.
A good illustration of this is a project my son took on the summer after finishing high school. That was a Hebrew word processing program. Lines were displayed from right to left and keys when typed showed up with Hebrew letters. And of course things like the shift key caused a shift of the cursor to the left , not to the right. What fun that project was! -- ======================================================================= If food be the music of love, eat up, eat up. ======================================================================= Aaron Konstam telephone: (210) 656-0355 e-mail: akonstam@sbcglobal.net
Hi Aaron;
[snip]
A second basic fact that needs to be undertood, which OP I think did not, is that what comes out of the keyboard or any other input device is just a stream of characters read from the appropriate buffer. What a program like vi does with that stream may make it look like a series of lines across the width of the window but that is an artifact of what vi does with the character stream it receives.
Being a little defencive perhaps, the original OP understood the process from keyboard matrix ==> scan codes ==> key codes ==> key maps. I understand the difference between a stream in raw versus canonical mode. And, what I have forgotten, I have saved in about 25 pages of cut and paste notes re: keyboards. I have enough 'C' to understand functions like getc() and getchar() and where getchar() gets its char.
My problem was on the other end. Although, one of the first things I learnt about Linux (actually all *nix) was that one of the very first things loaded at OS initialization was the shell, and that all processes were a child process of the shell. That was 'read and retain' kind of knowledge. It wasn't info that was "in my bones" as it should have been.
The reason I didn't know the answer to the query I posed here was that this was the first question that I have asked that directly depended on *knowing* that the shell was running and looking for input as the answer. When Rick Stevens said "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 ...", it was a real head slapping eureka moment . He brought home the significance of something that I already knew but hadn't appreciated. The shell is waiting for the right input (end of line) so that it can exec the program named.
I suppose there is some value in writing this response. I can serve as the classical bad example for people like me futzing around with their computers trying to figure out how they work.
On Saturday 25 August 2007 17:45, William Case wrote:
I have found there is a lot of information out there for "newbies" and a lot of exchanges of information for "gurus". But there is not much for those who have passed the newbie stage, but aren't yet ready to communicate with the gurus. People who you might call "newrus" or "gurbies".
Well, the terms "newbie", "newru", "gurbie" and "guru" are interpretation-dependent. Every person has a different amount of background knowledge related to particular subject, so it is very hard to create any kind of documentation that would classify knowledge somehow. At least, it is very ungrateful task.
A typical situation is when someone asks for a good book on learning C++. What is a "good book" strongly depends on whether or not he is already familiar with C, for example.
In general, the split of the documentation into "for gurus" and "for idiots" categories is the simplest one and easiest to write. I guess that is the reason why one encounters such docs most of the time.
What I would now like ask is, is someone saving, arranging, compiling, harvesting these middle level answers so they can easily be found by the newrus and gurbies of the world? I know how long I have spent searching for answers or explanations.
I have found the HOWTOs (www.tldp.org) quite full of information. The name suggests that they are a set of recipes for accomplishing certain tasks, but when one actually starts reading them, often one can also find information about what actually happens in the background and how is something designed (be it software, process, protocol, hardware, etc...). It came to me as a very nice surprise that the philosophy of writing HOWTOs was not just "if you do this and set up this, that will happen", but more down to "understand how this works, what you can set up, and then conclude what do you get as a result". When dealing with a particular problem, it is always better to *understand* what is going on, than to blindly follow instructions.
Of course, if your question goes deeper than what HOWTO covers, there is always a deeper level of documentation. Of course, the gap may sometimes be big and have a steep learning curve. And, contrary to Windows, there *is* the lowest level of documentation available, so if all other docs fail, use the Source, Luke! ;-)
I had such a situation some time ago. I was to write a custom app that needed *full control* of the keyboard (meaning that no keypress gets swallowed by any other app, no matter focus etc), and after reading all relevant HOWTOs, I finally understood the process of reading off keyboard input. But, there was nothing in the docs telling me how to lock the keyboard for my app. So, after some digging, I downloaded the very source code for the simple "showkey" program, and studied it. There, and only there, I actually found relevant info on what I needed to do in my app. After that, life was beautiful... ;-)
The moral of the story: there is no sharp line between a "gurbie" and a "guru". All you need to do is to be stubborn enough to read and learn, and you'll end up swimming in guru waters, without even noticing it.
Best regards, :-) Marko
Marko Vojinovic Institute of Physics University of Belgrade ====================== e-mail: vmarko@phy.bg.ac.yu
On Sat, 2007-08-25 at 20:42 +0000, Marko Vojinovic wrote:
I had such a situation some time ago. I was to write a custom app that needed *full control* of the keyboard (meaning that no keypress gets swallowed by any other app, no matter focus etc), and after reading all relevant HOWTOs, I finally understood the process of reading off keyboard input. But, there was nothing in the docs telling me how to lock the keyboard for my app. So, after some digging, I downloaded the very source code for the simple "showkey" program, and studied it. There, and only there, I actually found relevant info on what I needed to do in my app. After that, life was beautiful... ;-)
Speaking of such things, do you understand how xmodmap works? I'd been trying to do something in particular - to get some keys *somewhere* on the keyboard, so that I can easily type in the traditional opening and closing double quotes, as used in English text. A few others would have been useful, too, namely the EM and EN dashes. The idea sounded simple enough, but as best as I can tell, the xmodmap files only accept me adding characters found in ISO-8859-1, which doesn't include the ones I want to use. It's not my locale, that is set to UTF-8, xmodmap seems to be a rule unto itself.
I'm darned if I can find any documentation that helps me out, and it does look like xmodmap is going to be the only way to do this consistently across any application that uses the keyboard. VIM being the one that I use the most, I'm not using word processors for this task. I could live with only being able to do it within VIM, but it would be nice if everything worked the same way.
I have played with using the compose feature, which does allow me to type in things like æ, ü, etc., but it doesn't do the double quotes that I can see some cheatsheets say that it can, and it's a darn awkward set of composing characters to (allegedly) do so: COMPOSE SHIFT < "
It would be another acceptable way of typing them, if it worked. Though, I have to say that it'd be easier to do something like type ALT F11 or ALT F12, for one of them or the other, than the four key sequence that using the compose feature entails.
On Sunday 26 August 2007 04:36, Tim wrote:
On Sat, 2007-08-25 at 20:42 +0000, Marko Vojinovic wrote:
I had such a situation some time ago. I was to write a custom app that needed *full control* of the keyboard (meaning that no keypress gets swallowed by any other app, no matter focus etc), and after reading all relevant HOWTOs, I finally understood the process of reading off keyboard input. But, there was nothing in the docs telling me how to lock the keyboard for my app. So, after some digging, I downloaded the very source code for the simple "showkey" program, and studied it. There, and only there, I actually found relevant info on what I needed to do in my app. After that, life was beautiful... ;-)
Speaking of such things, do you understand how xmodmap works?
No, I don't. I gave up on understanding X keyboard handling. For the purpose of writing my app, it was enough to completely bypass X and read the keyboard stream directly.
X has a very complicated while simultaneously very limited (ie. stupid) keyboard controls. It does not make the difference between left ctrl and right ctrl, for example (if the keyboard happens to have both). Same for shift keys. While it is enough for a typical mouse-oriented user, it fails to support anything more advanced in terms of keyboard.
:-) Marko
Marko Vojinovic Institute of Physics University of Belgrade ====================== e-mail: vmarko@phy.bg.ac.yu
On 8/26/07, Marko Vojinovic vvmarko@panet.co.yu wrote:
X has a very complicated while simultaneously very limited (ie. stupid) keyboard controls. It does not make the difference between left ctrl and right ctrl, for example (if the keyboard happens to have both). Same for shift keys. While it is enough for a typical mouse-oriented user, it fails to support anything more advanced in terms of keyboard.
Are you sure about the L/R Ctrl part?
$ xmodmap -pm xmodmap: up to 3 keys per modifier, (keycodes in parentheses):
shift Shift_L (0x32), Shift_R (0x3e) lock Caps_Lock (0x42) control Control_L (0x25), Control_R (0x6d) mod1 Alt_L (0x40), Alt_L (0x7d), Meta_L (0x9c) mod2 Num_Lock (0x4d) mod3 mod4 Super_L (0x7f), Hyper_L (0x80) mod5 Mode_switch (0x5d)
In xev also, the two Ctrl keys show up as different keypresses.
So you can, say, switch off Ctrl_R with
xmodmap -e "clear control" xmodmap -e "add control = Control_L"
Andras
On Sunday 26 August 2007 16:07, Andras Simon wrote:
On 8/26/07, Marko Vojinovic vvmarko@panet.co.yu wrote:
X has a very complicated while simultaneously very limited (ie. stupid) keyboard controls. It does not make the difference between left ctrl and right ctrl, for example (if the keyboard happens to have both). Same for shift keys. While it is enough for a typical mouse-oriented user, it fails to support anything more advanced in terms of keyboard.
Are you sure about the L/R Ctrl part?
$ xmodmap -pm xmodmap: up to 3 keys per modifier, (keycodes in parentheses):
shift Shift_L (0x32), Shift_R (0x3e) lock Caps_Lock (0x42) control Control_L (0x25), Control_R (0x6d) mod1 Alt_L (0x40), Alt_L (0x7d), Meta_L (0x9c) mod2 Num_Lock (0x4d) mod3 mod4 Super_L (0x7f), Hyper_L (0x80) mod5 Mode_switch (0x5d)
Yes, this table exactly proves my point. There is only *one* control modifier (left column), to which *both* ctrl keys are mapped. So, there is no way for an application under X to know which of the two keys has been pressed, except to bypass X and read off the keyboard itself. If an app relies on X to handle the keyboard, Shift_L+a and Shift_R+a are the same thing, shift+a, as given by X to the app.
Of course, you can redirect Shift_R to be, say, mod3 instead of shift, but that would break all other apps that rely on both shift keys to be represented by the same X modifier.
In xev also, the two Ctrl keys show up as different keypresses.
Xev is similar to showkey, it reads keyboard (and mouse) events directly, bypassing X, simply because it is specially made for that purpose.
I do not argue that X does not see the two ctrl keys as different keys, but that it does not give that information further to a user app running on top of it, as displayed by your table above.
Let me clarify this with an example. Take any X app, say KMail (I'm writing this post in it, but any other app will do as well). I want to configure shortcuts for some actions, say sending mail and receiving mail on demand. I want to send mail by pressing Ctrl_L+a, while I want to receive mail by pressing Ctrl_R+a. (the sanity of such choice is for debate, but it is a legal one, in a way).
Is this possible to configure? No, it is not!
Why not? Because KMail knows nothing of left and right keys. It only knows of one and only ctrl modifier.
Who is the culprit? X, it deliberately abstracts this information between reading keyboard input and passing it to KMail. That is Bad Design, afaik. Completely unneeded limitation of hardware (keyboard) by software (X).
How to get around it? Make KMail read keyboard directly, not relying on X? Too complicated, hard to implement (although possible in principle).
Is this situation specific for KMail? No! Every X app is hosed this way, except for ones that are specifically written to circumvent this bad design (like xev, vmware, some games, etc).
End result? User needs to live with it, is forced to choose other shortcut key combinations, and hates X for bad keyboard handling. Like me. ;-)
Best, :-) Marko
Marko Vojinovic Institute of Physics University of Belgrade ====================== e-mail: vmarko@phy.bg.ac.yu
On Sat, 2007-08-25 at 10:00 -0700, Les wrote:
[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.
It seems to me that there is a point that is being missed. What you type on the keyboard is just a continuous stream of characters. A line feed which you get in Linux when you hit return is just a character like any other. When you hit a g the letter g is printed. When a text editor is analyzes the line feed it knows to go to the next line. When the shell sees the line feed it knows it is to treat everything on the line up to the line feed as a command. No magic is involved and it is really very simple. -- ======================================================================= Il brilgue: les t^oves libricilleux Se gyrent et frillant dans le guave, Enm^im'es sont les gougebosquex, Et le m^omerade horgrave. Es brilig war. Die schlichte Toven Wirrten und wimmelten in Waben; Und aller-mumsige Burggoven Dir mohmen Rath ausgraben. -- Lewis Carrol, "Through the Looking Glass" ======================================================================= Aaron Konstam telephone: (210) 656-0355 e-mail: akonstam@sbcglobal.net
Aaron Konstam wrote:
It seems to me that there is a point that is being missed. What you type on the keyboard is just a continuous stream of characters. A line feed which you get in Linux when you hit return is just a character like any other. When you hit a g the letter g is printed. When a text editor is analyzes the line feed it knows to go to the next line. When the shell sees the line feed it knows it is to treat everything on the line up to the line feed as a command. No magic is involved and it is really very simple.
It is on an even lower level that that - when you hit a g, a g may or may not be printed, depending on what is being done with the input. (For example, if I am playing a movie with mplayer, f toggles full screen mode, but is never printed.) Now, there are some libraries that make thing easy for the programmer. The reason that the editing keys work the same in so many programs is that they are using the readline library routines. (man readline)
You also have all the terminal control characters that can come into play, depending on the interface and settings. (man stty)
Mikkel
On Sat, 2007-08-25 at 17:24 -0500, Mikkel L. Ellertson wrote:
Aaron Konstam wrote:
It seems to me that there is a point that is being missed. What you type on the keyboard is just a continuous stream of characters. A line feed which you get in Linux when you hit return is just a character like any other. When you hit a g the letter g is printed. When a text editor is analyzes the line feed it knows to go to the next line. When the shell sees the line feed it knows it is to treat everything on the line up to the line feed as a command. No magic is involved and it is really very simple.
It is on an even lower level that that - when you hit a g, a g may or may not be printed, depending on what is being done with the input. (For example, if I am playing a movie with mplayer, f toggles full screen mode, but is never printed.) Now, there are some libraries that make thing easy for the programmer. The reason that the editing keys work the same in so many programs is that they are using the readline library routines. (man readline)
You also have all the terminal control characters that can come into play, depending on the interface and settings. (man stty)
Mikkel
Ok, I went too far. Whatever program contols processing the keyboard input uses anything typed in the way it wants to use it. The point is that lf is not unique in that regard. -- ======================================================================= Universities are places of knowledge. The freshman each bring a little in with them, and the seniors take none away, so knowledge accumulates. ======================================================================= Aaron Konstam telephone: (210) 656-0355 e-mail: akonstam@sbcglobal.net
On Saturday 25 August 2007 22:39, Aaron Konstam wrote:
On Sat, 2007-08-25 at 17:24 -0500, Mikkel L. Ellertson wrote:
It is on an even lower level that that - when you hit a g, a g may or may not be printed, depending on what is being done with the input. (For example, if I am playing a movie with mplayer, f toggles full screen mode, but is never printed.) Now, there are some libraries that make thing easy for the programmer. The reason that the editing keys work the same in so many programs is that they are using the readline library routines. (man readline)
You also have all the terminal control characters that can come into play, depending on the interface and settings. (man stty)
Ok, I went too far. Whatever program contols processing the keyboard input uses anything typed in the way it wants to use it. The point is that lf is not unique in that regard.
Just to emphasize that point some more --- *no* key is unique in that regard. Not even shift, control, alt, even "win" keys, multimedia keys, etc...
This is the democracy principle of the keyboard: All keys are created equal. :-)
How is the sequence of keystrokes interpreted by the software, and by which software, is entirely different question. It is quite easy to create an app where pressing left shift displays AA on the screen, while releasing it displays BB. Of course, the right shift does the same, only it writes CC and DD instead. All that, having 7+backspace+scroll lock combination to type "Hello world!", and open a new terminal...
Once your app starts reading the keyboard stream directly, there is no limit to what you can do, except by the hardware --- some keyboards can detect four simultaneous keypresses, some five or more, some just three or even two (although the latter are very rare). While that is the real difference in keyboard quality, people mostly buy keyboards based on look&feel, not even knowing that there may be some other parameters to consider... ;-)
Best, :-) Marko
Marko Vojinovic Institute of Physics University of Belgrade ====================== e-mail: vmarko@phy.bg.ac.yu
On Sat, 2007-08-25 at 17:39 -0500, Aaron Konstam wrote:
On Sat, 2007-08-25 at 17:24 -0500, Mikkel L. Ellertson wrote:
Aaron Konstam wrote:
It seems to me that there is a point that is being missed. What you type on the keyboard is just a continuous stream of characters. A line feed which you get in Linux when you hit return is just a character like any other. When you hit a g the letter g is printed. When a text editor is analyzes the line feed it knows to go to the next line. When the shell sees the line feed it knows it is to treat everything on the line up to the line feed as a command. No magic is involved and it is really very simple.
It is on an even lower level that that - when you hit a g, a g may or may not be printed, depending on what is being done with the input. (For example, if I am playing a movie with mplayer, f toggles full screen mode, but is never printed.) Now, there are some libraries that make thing easy for the programmer. The reason that the editing keys work the same in so many programs is that they are using the readline library routines. (man readline)
You also have all the terminal control characters that can come into play, depending on the interface and settings. (man stty)
Mikkel
Ok, I went too far. Whatever program contols processing the keyboard input uses anything typed in the way it wants to use it. The point is that lf is not unique in that regard. --
Except the keyboard produces 0x0d for the enter key (carriage return or C/R). The Unix or Linux software translates that to linefeed (0x0A). Some systems use (0x0d) to terminate lines, some use (0x0a 0x0d), some use (0x0d 0x0a) and some use these with the msb set. These are stored in the true literal text files, such as those produced by ed, edline or vi. Other word processors may treat them differently. Some use 0x0a to terminate a line, 0x0d or 0x8a to terminate a paragraph, and some use one of the embedded device controls of the ASCII set to control the paragraph or set editor appearance tools (such as the tab ruler, margins, header, footer, page number and so forth). How keys are handled are functions primarily of convention, where most of the conventions in English came from typewriters, just as the convoluted keyboard did.
Other conventions came from early word processors, and some came from user experience, where the choice of how to access menues and controls led to simpler key combinations for common actions.
Yet other conventions came from the unique capabilities of computers, such as the control keys, which allow accessing the serial bus control commands (note that the serial port on your computer is actually a bus for controlling peripherals as well as an input medium).
Still more came from advances in technology, like the command key or the function keys, and lately the keys for controlling sound or other dedicated keys. Again, these grew out of the need for common actions to be accessed in a simpler manner by the user.
Keyboards, continue to evolve, and new means and standards are probably going to emerge over time, as language, and systems use continues to evolve. Even the mouse was originally designed to evoke key strokes for its actions, and while mouse technology has evolved, the serial bus and its operation is still the medium of communication that has set the standard, although the mouse itself is now either connected wirelessly, by light or by usb. The mouse has grown buttons, scroll wheels accelerometers, feedback, and eliminated the ball, but the communications system is still "standard" to the serial port capabilities. At least in most cases.
Key mapping using a piece of middleware allows systems cross functionality, simplifies some operations and can even be set to interpret key stroke combinations to create more complex functions, as well as add the ability to create more accessibility for our handicapped users, or enhanced capability for those with great artistic bent in some unforeseen direction.
All of this is due to hackers, who looked at what was, saw what could be and then worked to fill the gap. OK, not all hackers are good guys, but most are. We benefit every day from them, from Mr. Diesel, to Mr. Ford, to Dr. Robert Godard. Even Tesla was a hacker and proud of it.
Regards, Les H
Except the keyboard produces 0x0d for the enter key (carriage return or C/R). The Unix or Linux software translates that to linefeed (0x0A).
Actually the keyboard produces a scancode. What that is translated into depends entirely on your keymaps (see man loadkeys) under the console, or your X keysym maps (see Xkb) under X11. For terminals its then controlled further by the termios settings (so in ancient times you could deal with the fact nobody could agree whether line-feed or carriage-return was the button in question (ditto del v backspace)
Its also the same mess that gives us tools like dos2unix (DOS uses both linefeed and carriage-return for new line marks, and like CP/M ^Z for EOF markers)
On Sun, 2007-08-26 at 20:28 +0100, Alan Cox wrote:
Its also the same mess that gives us tools like dos2unix (DOS uses both linefeed and carriage-return for new line marks
Though, understandable when you take into the origins of some keyboards and typing: Hit RETURN, and the head returns to the starting position, AND rolls down to the next line. The same applies for VDUs.
Mapping either one of CR or LF to do both jobs does make it a bit harder to use them by themselves to do just what they're named for.
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.
Indeed. Well written, both of them, and wonderfully complimentary.
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.
'Xactly. Just take the program 'more', for example. The way it reacts to an <ENTER> strike is not what you'd expect at all, if you're familiar only with command line or word processing stuff.
Andy
It sounds to me as though you are laboring under the false assumption that pressing <Enter> invokes some special system call, and that, for example, pressing <A> or <Spacebar> does not. Is this what you're thinking?
Over-simplifying:
Pressing any key simply produces a keycode. The system first looks and decides it has nothing to do with the <Enter> keycode, so it passes the keycode on to the next entity that might be interested in a key press.
For simplicity, lets say that the next guy is the Window Manager. The Window Manager examines the keycode and decides that it doesn't know how to handle this key, so it passes the keycode on to the next entity that might be interested in a key press.
We'll call the next entity the Focused Program. And here's where it gets interesting. The Focused Program receives the keycode and handles it by whatever context exists in the program. If the Focused Program is xterm or gnome-terminal or such then it does as you've described.
If the Focused Program has a Focused Widget (a text entry or menu or whatever) then it will likely pass the keycode on to the routines that handle events for that Widget, so that the Widget becomes the context for how the key is handled.
No magic. All keys are handled the same way. (With some special consideration for combination keys like <shift> or <ctrl>.)
If all of this is obvious to you then I've clearly misunderstood what you're having trouble understanding. If so, sorry, move along...
Thank you;
It does explain things -- somewhat.
On Fri, 2007-08-24 at 15:12 -0700, Alan M. Evans wrote:
It sounds to me as though you are laboring under the false assumption that pressing <Enter> invokes some special system call, and that, for example, pressing <A> or <Spacebar> does not. Is this what you're thinking?
Yes and no. Understood that all keys produce a keycode. My question -- as you have answered -- was what happens with that keycode after it was produced. Obviously, I one or two (or more) things can happen.
Over-simplifying:
Pressing any key simply produces a keycode. The system first looks and decides it has nothing to do with the <Enter> keycode, so it passes the keycode on to the next entity that might be interested in a key press.
For simplicity, lets say that the next guy is the Window Manager. The Window Manager examines the keycode and decides that it doesn't know how to handle this key, so it passes the keycode on to the next entity that might be interested in a key press.
This is a little too anthropomorphic for me; but I get the idea and it isn't the key part of the question.
We'll call the next entity the Focused Program. And here's where it gets interesting. The Focused Program receives the keycode and handles it by whatever context exists in the program. If the Focused Program is xterm or gnome-terminal or such then it does as you've described.
The main part of your answer is that each program somewhere in its programming has a function() or whatever on how the program will respond to various keycodes. I understand how this works for key intesive programs like emacs. But you are saying that this equally applicable to all programs. That I could, if I wanted change the function of RET by changing the keymap a particular application uses. It is just that the use of RET is fairly well standardized.
If I have understood you properly, all this makes sense.
If the Focused Program has a Focused Widget (a text entry or menu or whatever) then it will likely pass the keycode on to the routines that handle events for that Widget, so that the Widget becomes the context for how the key is handled.
No magic. All keys are handled the same way. (With some special consideration for combination keys like <shift> or <ctrl>.)
If all of this is obvious to you then I've clearly misunderstood what you're having trouble understanding. If so, sorry, move along...
The mechanics you have explained is obvious to me and therefore understandable. I suppose, I had assumed, (incorrectly), that because the RET key was so rudimentary and used right from the beginning of a computer session it was predefined somewhere in init or the kernel; that changing its function, for example, was next to impossible because in some way it was unlike other keys.
Thank you for the clarification.
I came at this question by originally wondering how pushing RET actually issued some command to fire up, start, begin, execute the named program on the command line and where that command or function resided. I knew somewhere an exec or fork command had to be involved. It is obvious to me that if the focus as you outlined falls on the shell then the shell interprets the RET as a a fork or whatever command.
programs like emacs. But you are saying that this equally applicable to all programs. That I could, if I wanted change the function of RET by changing the keymap a particular application uses. It is just that the use of RET is fairly well standardized.
Its partly wired in. Certain parts of the behaviour are encoded into the terminal layer in the kernel (originally designed from the days people sat at terminals with serial links (or current loop) to the box in the data centre.
In normal line by line behaviour the return key is fixed (you can pick between carriage-return and line feed that is all), but the other 'special' characters like the delete key can be changed. This is so called "canonical" or "cooked mode". You can turn this off to do character by character processing (as emacs does) which is "raw mode".
The idea of cooked mode is that most programs at the time wanted lines of typed input so the kernel handles this to ensure the editing behaviour was standard, it was efficient and on big machines (with hundreds of terminals) you didn't wake processes each keypress. Indeed some machines had serial ports that didn't wake the machine but supported all the line editing features in hardware until you hit return.
Thanks again Alan;
On Sat, 2007-08-25 at 00:36 +0100, Alan Cox wrote:
programs like emacs. But you are saying that this equally applicable to all programs. That I could, if I wanted change the function of RET by changing the keymap a particular application uses. It is just that the use of RET is fairly well standardized.
Its partly wired in. Certain parts of the behaviour are encoded into the terminal layer in the kernel (originally designed from the days people sat at terminals with serial links (or current loop) to the box in the data centre.
In normal line by line behaviour the return key is fixed (you can pick between carriage-return and line feed that is all), but the other 'special' characters like the delete key can be changed. This is so called "canonical" or "cooked mode". You can turn this off to do character by character processing (as emacs does) which is "raw mode".
The idea of cooked mode is that most programs at the time wanted lines of typed input so the kernel handles this to ensure the editing behaviour was standard, it was efficient and on big machines (with hundreds of terminals) you didn't wake processes each keypress. Indeed some machines had serial ports that didn't wake the machine but supported all the line editing features in hardware until you hit return.
A year or so ago when I was reading about keyboard input and tty, I came across canonical mode, and couldn't figure out what it would be used for, shrugged (kinda), assumed it was only of historical interest and moved on. I will re-visit canonical mode and see how it applies.
For 1) How does the context (i.e. that I am in a text program) get established? Is there a context line at the start of the application? Is it through main(argc, argv) or some such, depending on the programming language of the application? How does it know to move one line down on the screen i.e. is there a system call, a special function ?
man termios will teach you more than you ever want to know.
Thanks Allan;
On Sat, 2007-08-25 at 00:19 +0100, Alan Cox wrote:
For 1) How does the context (i.e. that I am in a text program) get established? Is there a context line at the start of the application? Is it through main(argc, argv) or some such, depending on the programming language of the application? How does it know to move one line down on the screen i.e. is there a system call, a special function ?
man termios will teach you more than you ever want to know.
True you are. I read through termios and friends. I had no idea what most of it is about. On the other hand, understanding things like termios is what I am working towards. I could glean enough info to know my answer lay within.
Therefore while your answer is a "Greek to me" answer; still it tells me that my question was not stupid but on the right track. If I keep learning it will eventually make sense.
By the way, just received your second post. You anticipated my next question, so I won't ask it.
You answered me personally. Was that on purpose? I think that although the original question might have been off topic for the Fedora list, your answer is one that should be shared.
On Fri, 2007-08-24 at 17:42 -0400, William Case wrote:
I suppose there is a simple answer; there should be. 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.
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.
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.
William Case wrote:
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.
The executable doesn't start itself. Bash is the one that detects the RET keycode and starts the executable program (going through the kernel).
The shell is always running/sleeping -- waiting for input.
Right, and Xorg is on top of the shell for most people.
Matt Flaschen