| Filename | Latest commit message | Latest commit date |
|---|---|---|
ff7afa746e
Three things, all in the first minute of using a shell.
**Arrow keys corrupted the two keystrokes after them.** They arrive as single
keycodes -- KEY_UP is 0xE2 -- and were pushed into the input buffer exactly
like that. No terminal works that way, and 0xE2 is the worst possible byte to
have chosen: it is a UTF-8 lead byte for a three-byte character, so a reader
decoding UTF-8 swallowed the next two keys waiting for continuations that never
arrived. consoleintr() sends the DEC/xterm sequences now -- ESC[A, ESC[D,
ESC[5~ and the rest -- which every terminfo entry and every line editor already
knows. Not echoed: in canonical mode echoing them would move the cursor for
real, which was the other half of what "weird glitches" looked like.
**Then the end of the line vanished as you typed into it**, with the buffer
perfectly correct. One line in vt_putc(): backspace erased the cell it moved
onto. That is a line-discipline erase, not the BS control character -- a
program rubbing a character out sends `\b \b`, and the separation matters
because programs also use plain `\b` to go back. zsh does, on every mid-line
edit:
echo alpha \b\b zha \b\b
back two, rewrite the tail, back two again to park the cursor. Against a
destructive backspace that last pair deleted the `ha` it had just drawn.
`\b` moves and nothing else now, 0x7f is ignored as on a real terminal, and
consputc() spells its own erase out as `\b \b` as it already did for serial.
ESC[@, ESC[P and ESC[X went in alongside, because TERM=linux declares them.
**VT3 to VT6 were blank** because nothing ran on them. NVT is 6 and the kernel
made all six; only two had a shell, so Alt+F3 switched to a terminal that was
working perfectly and had nobody to talk to. Four more manifests.
Six shells starting at once is enough concurrency to expose an intermittent
fault in one of them -- one boot in five, a wild jump into .data that runs
until it writes to 0, which nothing catches because SchOS never sets EFER.NXE.
Three boots with two shells, none. Recorded rather than fixed: it is not caused
by the manifests, only made likelier by them.
Also: QEMU_NET forwards host 8080/8081/8000 to guest 80/8080/8000, so the httpd
is reachable from the machine running QEMU instead of being sealed behind NAT.
Verified end to end. And the greeting prints once again -- a replaced
supervisor was announcing a boot that had already happened.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VQ7Qx8E1q1M1bbCq8QLHS2
|
||
| .. | ||
| console-shell.job | ||
| README | ||
| resolvconf.job | ||
| schdbgd.job | ||
| tty2-shell.job | ||
| tty3-shell.job | ||
| tty4-shell.job | ||
| tty5-shell.job | ||
| tty6-shell.job | ||
| vgpud.job | ||
Job manifests for schinit, SchOS process 1.
Every *.job file in this directory is loaded at boot. Format is sectioned
key = value; # starts a comment, keys are case-insensitive.
Label a reverse-DNS name, as launchd uses. Identity, not a path.
Program the binary to execute
Args argv, space separated. argv[0] is conventionally the
basename, so `Args = sh` for `/bin/sh`.
RunAtLoad start it when schinit loads
KeepAlive restart it when it exits
Disabled load it but do not start it
ThrottleInterval seconds between respawns (default 1)
StandardIn \
StandardOut > paths to open as fd 0, 1, 2
StandardError /
[Socket <name>]
Path a unix socket schinit will hold on the job's behalf and
start the job on first connect
A KeepAlive job that exits with status 78 (sysexits.h's EX_CONFIG) is not
restarted, and schinit says which job stopped and that it stopped on purpose.
This is for a program that has looked at the machine and found nothing here it
can run against -- a driver whose device is absent, say -- which would otherwise
report the same thing every ThrottleInterval for the rest of the uptime. A job
that was killed or crashed carries a signal in its status, never matches, and
comes back exactly as KeepAlive promises.
Socket sections are parsed but not yet acted on -- that is milestone 2, and
demand launching is the whole reason this is shaped after launchd rather than
sysvinit. The key exists now so manifests do not have to change later.
Unknown keys and unknown sections are ignored rather than fatal: a manifest
written for a newer schinit must not stop this one booting the machine.