Tab reaches the disk

Paths and programs, which is the half that makes it worth having. The first word
of a line is a command or a PROGRAM, offered under the name somebody would type
- the extension taken off - and anything after it is a file, offered as it
really is. A separator anywhere in the word says which directory to look in.

A directory answers with a separator on the end instead of a space, which says
what it is and lets the next part be typed straight away. The answer ending in
one is also what stops a space being added, so that is one test rather than a
flag.

PROGRAMS ARE LOOKED FOR WHERE THE SHELL WOULD LOOK to run one: where you are,
/Apps on the disk you are on, and /Apps on drive 0. Offering something the shell
would not find would be finishing a word into a thing that then does not work.
Drive 0's is skipped when that is already the drive, or every program in it
would be offered twice and nothing would ever be the only match.

Walking somebody else's directory means standing in it, which is the only way to
walk one here, so where the person was and which drive they were on are put down
first and restored whatever happens.

Three bugs, all found by running it:

THE DIRECTORY TEST WAS INVERTED. dir asks the same question the same way round
four hundred lines further up, which is what made it obvious once looked at.

THE /Apps WALK OVERWROTE THE TYPED PATH. The whole search runs a second time to
list the matches, and by then TabDir said "/Apps" - so a word that had named
nowhere went looking in the wrong place and listed nothing at all. Two ways into
the walk now, and the typed path is never written over.

AND LISTING ONLY KNEW ABOUT COMMANDS, because it was a second copy of the walk.
It is the same walk with a flag now: finding the answer and showing the matches
are the same question asked twice.

Also cosmosMonitor, which had been RE-BLESSED INTO MEANINGLESSNESS by the wall
move. It disassembles a loaded program, at an address the input names - and that
address moved a page while the recording was simply re-recorded to whatever came
out, which was a page of zeroes. It is pointed at 5000 again.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E2JrLzFvuFX9fgi1LDRjrW
This commit is contained in:
Anachronaut
2026-09-01 18:10:40 -04:00
co-authored by Claude Opus 5
parent bb065fe221
commit 3c76934a9a
9 changed files with 551 additions and 132 deletions
+24 -7
View File
@@ -315,14 +315,31 @@ should be on it, and the shell decides.
### Finishing A Word:
Tab finishes the **first** word of a line against the shell's own commands. One match goes in
with a space after it, because a word that can only be one thing is finished. Several are
folded into their longest common prefix and that goes in, which is the most that can be said
without guessing which was meant - and if that adds nothing, because what is typed is already
as far as they all agree, the matches are listed and the line put back underneath.
Tab finishes the word being typed. One match goes in with a space after it, because a word
that can only be one thing is finished. Several are folded into their longest common prefix
and that goes in, which is the most that can be said without guessing which was meant - and
if that adds nothing, because what is typed is already as far as they all agree, the matches
are listed and the line put back underneath.
Nothing typed and nothing matching both do nothing, quietly. Finishing an argument rather
than a command is not built yet.
**What it can be depends on where in the line it is.** The first word is a command or a
program; anything after it is a file.
| Where | What is offered |
| -- | -- |
| The first word | the fifteen commands, and programs - under the name you would type, with the extension taken off |
| After it | anything on the disk, under its real name |
| Either, with a `/` in it | whatever is in the directory the word names |
A directory answers with a separator on the end instead of a space, which says what it is and
lets the next part be typed straight away.
**Programs are looked for in the three places the shell would look to run one**: where you
are, `/Apps` on the disk you are on, and `/Apps` on drive 0. Offering something the shell
would not find would be finishing a word into a thing that then does not work. A program that
is in two of those places is offered twice and so is never the only match, which costs it the
space after it - the shell is comparing names, not deciding which file it would have run.
Nothing typed and nothing matching both do nothing, quietly.
**This is the same wall the history was behind.** A shell that never sees a keystroke has no
moment at which somebody has typed half a word - the terminal hands over finished lines - so