The shell edits the line it is given
Three different things used to do this job, and which one you got depended on where the machine was running. On a terminal the host held the line and did the echoing and the backspacing; behind a window the console's own gatherer did it; from a file nothing did it at all. One job, three implementations, none of them in the system - which is why there was no way to move about in a line and nowhere for a history to live. So editLine does it. Key mode while a line is being read and line mode straight after, so nothing else in the system and no program calling osReadLine notices anything changed. Left and Right, Home and End, Backspace for the character before the cursor and Delete for the one under it, and anything typed goes in where the cursor is with the rest of the line moving along. Ctrl-D means the end of input again, on an empty line, because that was a thing the terminal did while it was holding the line and it is not holding it now. Same trade as the echoing. MOST KEYSTROKES DRAW NOTHING BUT THEMSELVES. A character typed at the end of a line needs no cursor moved: printing it is the whole change, and a backspace there is three ordinary bytes. That matters beyond speed - moving the cursor by hand is what a terminal is TOLD about, in an escape sequence, so redrawing on every keypress would fill every recorded transcript in this suite with them. The line is only reprinted when something happened in the middle of it. Where the line STARTS is worked out backwards from where printing ended, rather than trusted from what was remembered. That is what makes it survive the screen scrolling: a line printed on the bottom row moves everything up by one, and a remembered row would be one too low from then on. The command line holds 127 characters, up from 63. The limit started to be felt the moment a line could be moved about in. 58 recordings changed, and every one of them by the echo. THE PROOF IS NOT A HEURISTIC: a CosmOS built with the echo silenced reproduces 187 of the 188 recordings byte for byte. The one exception is cosmosTyped, the backspace test, where the rub-out marks now come from the shell instead of from the console's gatherer - same marks, different author. cosmosEditKeys is the new test, and every line in it is typed wrong and then corrected with a different key. Its last line is eighty six characters at a prompt in column two on an eighty column screen, so the line runs onto the row below and the shell has to find the start of something it can no longer see; breaking either half of that arithmetic fails it. Also: agree.sh looked for "> the same", anchored to a prompt that no longer precedes what a command prints. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01E2JrLzFvuFX9fgi1LDRjrW
This commit is contained in:
co-authored by
Claude Opus 5
parent
b3726c950a
commit
736037462e
@@ -283,6 +283,37 @@ facility and as a test that CosmOS correctly restores its Stack and vector table
|
||||
every run; and `load` is how the monitor puts an arbitrary file in front of itself, which
|
||||
is a thing typing a name deliberately cannot do.
|
||||
|
||||
### Typing A Line:
|
||||
|
||||
The shell reads what you type a key at a time and edits the line itself, which is why the
|
||||
line can be moved about in at all.
|
||||
|
||||
| Key | What it does |
|
||||
| -- | -- |
|
||||
| Left, Right | Move a character. |
|
||||
| Home, End | Go to the start of the line or the end of it. |
|
||||
| Backspace | Take out the character before the cursor. |
|
||||
| Delete | Take out the one under it. |
|
||||
| Return | Finish the line, wherever the cursor happens to be sitting. |
|
||||
|
||||
Anything typed goes in where the cursor is, so a word left out of the middle of a line is
|
||||
put back by moving there and typing it, and the rest of the line moves along.
|
||||
|
||||
**This used to be three different things depending on where the machine was running.** On a
|
||||
terminal the host held the line and did the echoing and the backspacing; behind a window the
|
||||
console's own gatherer did it; from a file nothing did it at all. One job, three
|
||||
implementations, and none of them here - which is why there was no way to move about in a
|
||||
line, and nowhere for a history to live. Now the console delivers keys and says nothing
|
||||
about what they mean, the same way it reports what a drive is and says nothing about what
|
||||
should be on it, and the shell decides.
|
||||
|
||||
The line holds 127 characters. It held 63 until the shell could edit one, which is when the
|
||||
limit started to be felt: a copy between two disks with a directory on each is most of the
|
||||
way there before anything has been said.
|
||||
|
||||
Everything else that reads a line - an application calling `osReadLine`, the editor - is
|
||||
unchanged and still gets a plain line with no editing in it.
|
||||
|
||||
### Paths:
|
||||
|
||||
Everywhere CosmOS takes a filename it will take a path: names with `/` between them,
|
||||
|
||||
Reference in New Issue
Block a user