Stop the prompt writing off the front of its own buffer

The prompt is the working directory's path, worked out each time by walking
the chain of parents up to the root. The names arrive deepest first, so
they are written backwards from the end of a 127 byte buffer - and nothing
bounded that walk.

Nothing bounds the depth either. A path given to one operation is capped at
95 characters and a 22 character name, but "mkdir a" and "cd a" are each
far inside that and can be repeated forever. Six directories of 22
characters is 132 characters of path, and at that point the walk wrote down
past the front of CwdText and into what the assembler had laid out below
it: the shell's own command names. ExitName sits five bytes under, so the
word "exit" went first and the shell stopped recognising the command for
leaving. Measured, not deduced: fine at five levels, gone at six.

The walk now counts the room it has left, byte by byte, and stops. What is
already written is the DEEP end of the path, which is the end worth
showing, so it is cut at the front and three dots say so - out of three
bytes held back from the count, so there is always somewhere to put them.
Twenty levels deep the prompt shows the last five and every command still
works.

cosmosDeep records that, and records it by running help, cd and exit from
down there rather than by looking at the prompt: a wrong prompt is
cosmetic, and this was writing into other variables. It fails with the
bound removed. The tree is built by SplitDisk because a path that long
cannot be given to mkdir in one piece - which is the same fact that makes
the depth unbounded.

The three path limits are written down in the README now, including which
one actually binds. The other two do not: the longest path on a full
install is 21 characters.

Programs/CosmOS/README.md

@@ -185,6 +185,29 @@ has moved about on looks exactly as it always did. Nothing stores the path: the
 directory is an entry index and two bytes, and the text on the prompt is worked out again
 each time by walking the chain of parents upward.
 
+That walk goes from where you are up to the root, so the names arrive deepest first and
+are written into the buffer **backwards, from its end**. When they do not all fit, what is
+already down is the deep end of the path, which is the end worth keeping - so the prompt
+is cut at the front and says so:
+
+```
+...opqrst03/abcdefghijklmnopqrst04/.../abcdefghijklmnopqrst08>
+```
+
+**Three limits, and the smallest is not the one you would guess.** A path handed to any
+one operation is capped at 95 characters up to the last separator plus a name of 22; the
+host tool carries 512, which only means it can build a tree CosmOS cannot name in one
+piece. Neither of those binds anything: the longest path on a full install is 21
+characters. What binds is the prompt's 127 bytes - and **nothing caps how deep the
+directories go**, because `mkdir a` and `cd a` are each well inside every limit and can be
+typed all day.
+
+Before the walk was bounded it wrote past the front of that buffer and into whatever the
+assembler had put below it, which was the shell's own command names. Six directories of 22
+characters was enough. The first five bytes to go were the word `exit`, so the shell
+stopped recognising the command for leaving - a fault with no plausible connection to the
+directory you happened to be standing in.
+
 `dir` lists the directory you are in rather than the whole disk.
 
 A program can move too, with `osChangeDir`, and **the shell puts the working directory

Programs/CosmOS/Source/cosmos.asm

@@ -1235,6 +1235,23 @@ shellPath:
   SETD.1 CwdAt
   STD.0.1
 
+  ; HOW MUCH THERE IS TO WRITE INTO, COUNTED DOWN. Nothing bounds how deep the directories
+  ; go: a path is capped at what one operation can name, but "mkdir a" and "cd a" are each
+  ; well inside that and can be typed all day. This walk writes BACKWARDS from the end, so
+  ; running out means walking off the FRONT of the buffer and into whatever the assembler
+  ; put below it - which was the shell's own command names. Six directories of twenty two
+  ; characters was enough, and the first five bytes to go were the word "exit", so the
+  ; shell stopped recognising the command for leaving.
+  ;
+  ; A hundred and twenty three of the hundred and twenty six, the other three being kept
+  ; back for the dots that say it was cut.
+  INIA 0d123
+  SETD.0 CwdRoom
+  STA.0
+  RSTA
+  SETD.0 CwdCut
+  STA.0
+
   ; Where the walk up starts.
   SETD.0 SbfsCwd
   SETD.1 CwdWalk
@@ -1259,6 +1276,9 @@ shellPathStep:
   ; The name goes in front of what is there, and a separator in front of that.
   SETD.0 SbfsName
   CALL shellPathPrepend
+  SETD.0 CwdCut
+  LDA.0
+  BNA shellPathReady    ; It would not all fit, so there is nothing above worth asking for.
 
   SETD.0 SbfsUpParent
   SETD.1 CwdWalk
@@ -1307,6 +1327,13 @@ pathBack:
   BRA pathSeparator
   DECA
   STA.1
+
+  SETD.1 CwdRoom
+  LDA.1
+  BRA pathCut           ; The front of the buffer, and the next byte would be past it.
+  DECA
+  STA.1
+
   DECD.0
   DECD.2
   LDA.0
@@ -1314,6 +1341,12 @@ pathBack:
   BRI pathBack
 
 pathSeparator:
+  SETD.1 CwdRoom
+  LDA.1
+  BRA pathCut
+  DECA
+  STA.1
+
   DECD.2
   INIA 0x2F
   STA.2
@@ -1321,6 +1354,28 @@ pathSeparator:
   STD.2.1
   RET
 
+; Stopping rather than writing past the front. The names go on backwards, so what is
+; already down is the DEEP end of the path - which is the end worth showing: the prompt
+; says where you are, and the last two directories say that better than the first two do.
+;
+; Three dots in front, out of the room that was never counted, so there is always
+; somewhere to put them. No separator: the name they sit against brought its own, or was
+; cut off half way, and "..." reads correctly against either.
+pathCut:
+  INIA 0x2E
+  DECD.2
+  STA.2
+  DECD.2
+  STA.2
+  DECD.2
+  STA.2
+  SETD.1 CwdAt
+  STD.2.1
+  INIA 0x01
+  SETD.1 CwdCut
+  STA.1
+  RET
+
 ; ---- delete and rename ----
 ;
 ; The two things a disk needs that reading and writing do not provide, and the two that
@@ -3534,6 +3589,15 @@ CwdWalk:
 PathLength:
   0x00
 
+; What is left of CwdText to write into, and whether the path ran out of it. Counted down
+; rather than compared against an address, because the check is on every byte written and
+; a subtraction of two pointers is a great deal more than a byte that is already going to
+; be tested for zero.
+CwdRoom:
+  0x00
+CwdCut:
+  0x00
+
 ; What the working directory was when a program was started, so that it can be put back
 ; when the program stops.
 SavedCwd: