Finishing says nothing, which is what finishing looks like

The shell printed "finished" every time a program gave the machine back.
That made sense when starting a program and getting the machine back was
most of what the machine did and the prompt was the only other thing on
the screen. Under a listing, between two commands, it is noise.

And it was printed whatever the program made of it, so a program that had
just explained what went wrong was answered with the word "finished" -
"there is no such directory: nowhere" and then, immediately, "finished".

The prompt coming back is what says a program is over. It is the same
argument osLastStatus is made of: a program that failed has already said
so in words, and anything the shell adds beside that is the shell talking
over it. A program that FAULTED still says so, because the fault screen
printed in red above and a program that is gone should not look like one
that ended.

A NEWLINE ONLY IF ONE IS WANTED. A program that stopped part way along a
line would leave the prompt sitting in the middle of its last output,
which the word used to prevent by accident. The console knows which
column the cursor is in, so the shell asks - where a blank line printed
every time would be right about half of the time, and an empty directory
listed with ls would be followed by a blank line for no reason.

Fifty nine recorded sessions lose the word. Two of them move a cursor up
a row with it, which is the same fact seen from the screen.

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-06 19:49:43 -04:00
co-authored by Claude Opus 5
parent a13bbeb4db
commit afda6ca83b
60 changed files with 43 additions and 151 deletions
+4 -5
View File
@@ -199,12 +199,10 @@ lsColour:
; ---- What it is, said in colour ----
;
; The attribute reaches a terminal as well as the screen now, so this is one mechanism and
; not two. A directory in blue and an unfinished save in red; everything else plain, because
; whether a file is runnable cannot be known without opening it, and opening every file in a
; directory to colour a listing is a price nobody agreed to pay.
; not two. A directory in blue and an unfinished save in red; everything else plain.
SETD.0 Kind
LDA.0
BRA lsPlain
BRA lsFileInk
DECA
BRA lsBlue
INIA 0d1 ; An unfinished save, which is worth looking at.
@@ -212,7 +210,8 @@ lsColour:
lsBlue:
INIA 0d4
BRI lsInk
lsPlain:
lsFileInk:
RSTA
lsInk:
OUTA 0x06
+2 -1
View File
@@ -274,7 +274,8 @@ echo done
`echo` is a command rather than a program on purpose. `Say.sbx` has printed words since before
there were scripts and is the wrong shape for one: being a program, it has to be found on the
disk and loaded and started, it prefixes what it was told with `it says:`, and the system
prints `finished` after it - three lines of noise around one line of narration.
prints `finished` after it - three lines of noise around one line of narration. Two, now: the
system stopped saying `finished` after every program.
**The first two bytes must be `#!`**, or the shell refuses the file and says so. That is what
tells a script from anything else, and it is deliberately not the name and not a flag in the
+27 -12
View File
@@ -5126,8 +5126,9 @@ doClear:
;
; Says the rest of the line and nothing else. Say.sbx has done this since before there were
; scripts, and is the wrong shape for one: it is a program, so it has to be found on the
; disk and loaded and started, it prefixes what it was told with "it says:", and the system
; prints "finished" after it. That is three lines of noise around one line of narration.
; disk and loaded and started, and it prefixes what it was told with "it says:". That was
; three lines of noise around one line of narration when this was written - the system said
; "finished" after every program then, which is the third line and is gone now.
;
; A script telling you what it is doing is the ordinary case now, so it costs a command
; rather than a program. With nothing after it, a blank line - which is what anybody will
@@ -6830,24 +6831,41 @@ exitWorked:
RSTA
OUTA 0x06
; ---- Finished, or stopped ----
; ---- Stopped, or nothing at all ----
;
; A program that faulted did not finish, and saying so would be the shell's own word
; against what the fault screen just said in red immediately above it.
; A program that faulted did not finish, and says so - the fault screen printed in red
; immediately above, and a program that is gone should not look like one that ended.
SETD.1 FaultStopped
LDA.1
BRA exitFinished
RSTA
STA.1 ; Cleared, so the next program is not blamed for this one.
SETD.0 Stopped
BRI exitSay
exitFinished:
SETD.0 Finished
exitSay:
CALL printString
CALL newLine
BRI prompt
exitFinished:
; ---- Finishing says nothing, which is what finishing looks like ----
;
; It used to say "finished". That made sense when starting a program and getting the
; machine back was most of what the machine did; under a listing, between two commands, it
; is noise - and it was printed whatever the program made of it, so a program that had just
; explained what went wrong was answered with the word "finished".
;
; The prompt coming back is what says a program is over. It is the same argument
; osLastStatus is made of: a program that failed has already said so in words, and anything
; the shell adds beside that is the shell talking over it.
;
; A NEWLINE ONLY IF ONE IS WANTED. A program that stopped part way along a line would leave
; the prompt sitting in the middle of its last output, which the word used to prevent by
; accident. The console knows which column the cursor is in, so this asks - where a blank
; line printed every time would be right about half of the time.
INA 0x04
BRA prompt
CALL newLine
BRI prompt
; ---- dump ----
;
; dump Sixty four more bytes, carrying on from the last one.
@@ -8127,9 +8145,6 @@ FaultQ:
" Q "
FaultSystem:
"that was the system itself, so there is nowhere to carry on from. Start the machine again."
Finished:
"finished"
BreakText:
"break at "
ARegText: