Update and versions

koshi update

koshi update installs the newer release the way koshi was installed:

If the installed version is the latest, it says so and exits successfully. Network, platform, archive, checksum, permission, and install failures return an update error.

On Linux and macOS, the new file replaces the old one in one rename. A program file in a root-owned directory, such as /usr/local/bin, is installed with sudo install -m 755. On Windows, the running koshi.exe is renamed to koshi.old, or koshi.1.old and onward while a koshi still runs from an older backup, and the new one takes its path. Each interactive launch removes the backups no koshi runs from. While it replaces the file, koshi update holds a lock on koshi.lock beside koshi.exe, so a second install waits.

The running sessions move too

After every update, whether or not it installed a release, koshi update restarts each running session into the installed koshi, and then the router, the background process that tracks sessions. A release install skips a session that already runs the installed version. A build from source restarts every session.

A session keeps its panes, the programs running in them, and their scrollback. Saved sessions, config files, remote access records, saved servers, certificates, and runtime files are converted to the new build's formats as it opens them.

An attached client comes back to its session on its own, as the same client: on the same tab with the same focus, fullscreen, scroll positions, selections, lock mode, and floating panes. Keys typed while it reconnects reach the restarted session in order. The session keeps the record of a client that has not come back for 60 seconds after it restarts. A client from koshi 0.5.0 comes back as a new client. A client of a session on another machine prints the attach command to run instead.

Sessions started by koshi 0.3.0, 0.4.0, 0.5.0, or 0.6.0 restart this way. A session or router of koshi 0.3.0 or 0.4.0 does not restart by itself after a package manager installs a new koshi; run koshi restart-servers once. A session started by koshi 0.2.0 cannot move to a new build: koshi update and koshi restart-servers name each such session and ask once whether to end it and the programs in its panes. A koshi 0.1.0 window keeps its build until its terminal closes.

If a session cannot read its restart record, it opens one new shell and posts the session could not be restored after the restart; a new shell started to every client that attaches.

A session refuses the restart when:

• a pane's program stopped reading its input;
• a pane has no terminal to carry;
• this machine cannot run the new binary;
• the new binary does not read the resume file this build writes.

A session running a koshi with no restart at all, one that still reports the old version after the restart, and one that answers nothing within ten seconds are all reported the same way.

restart-servers

koshi restart-servers

Restarts every running session, then the router, into the koshi program on disk, and installs nothing. Use it after koshi is installed another way, such as by a package manager. Every pane keeps running. The command prints one line per server, and exits 1 if any server does not come back on the version of the koshi that ran the command.

A running session or router also restarts by itself when the koshi program it started from now holds another version: the next koshi command that connects to it starts the restart.

Which build is running where

koshi version                  # the koshi program you just ran
koshi server-version           # every running koshi server
koshi server-version --session <NAME_OR_ID>
koshi server-version --format json

koshi version prints the same line as koshi --version:

koshi version
koshi 0.6.0

The two answers differ while an update rolls out — the program your shell runs is a newer build than the process answering it until every restart lands:

koshi server-version
kind     session                                       version
router   -                                             0.6.0
session  session-3f2a1c94-8e7b-4d15-9a02-6c5138ef7b40  0.6.0
session  session-91c4de07-2b53-41a8-bf6e-70d9a2c81f35  0.5.0

A server that could not be asked does not stop the rest of the answer: the other rows still print, and the command exits 4. Everything answering exits 0, including a machine running nothing at all.

--session reports that one session and leaves out the router. It takes the session id or its exact generated name, and a name must match exactly one running session.

Startup checks

Interactive launches can check on an interval and ask before installing:

version 2

update {
    auto-check #true
    check-interval-days 14
    allow-prerelease #false
}

With auto-check #true, koshi checks in the background while it runs and offers a newer release it found at the next start. Startup check failures never block or crash a normal launch. koshi stores only the last-check time in update.json in its state directory; it never rewrites koshi.kdl. A build from source checks nothing.

allow-prerelease #true lets the startup check and koshi update choose pre-releases too. A Homebrew install is offered stable releases only.