Obsidian in Other Commands

This page lists the Obsidian rows that commands outside the group flint obsidian print. It also lists the Obsidian commands that 0.7.0 removed. CLI Commands holds the help of each command. Using Obsidian explains the model.

Obsidian in Other Commands

The help does not show these rows. In the tables, <release> is a payload release, for example 0.7.0. <name> is the name of the Flint, and <path> is its folder. <config path> is the Flint CLI config of this build: <NUU home>/flint/config.toml (a dev build: <NUU home>/flint-dev/config.toml).

Loading Rows

A slow Obsidian step shows a loading row on stderr while it runs. In a terminal, the rows are a live frame, and the command removes the frame before its result lines. The rows are not part of the result.

Outside a terminal, the rows differ by command:

• flint create, flint sync, flint open, and flint obsidian update: in a pipe, with --json, or with NO_COLOR, the rows are plain lines.
• flint delete, flint move, and flint obshn: the rows show only when stderr and stdout are both a terminal, with no NO_COLOR and no --json (terminalOnly() in apps/flint-cli/src/output/loading-row.ts). In a pipe, with a redirected stdout, with --json, or with NO_COLOR, these commands print no row and no control sequence.

flint create

flint create pins the recommended release and installs the Obsidian payload. Then it opens the vault in Obsidian, but only in a terminal and without --json. --open and --no-open decide when you give them. --no-open skips only the launch: the payload is installed. --no-obsidian skips Obsidian for this run only, and it writes no config. The open step runs flint open (see below): when no Obsidian process runs, it can write the vault registry entry of the new Flint before it launches Obsidian. With --no-open, flint create writes no vault registry entry.

A payload that does not install never fails flint create. The exit code is 0, and the Flint is ready for CLI work. flint create then does not open the vault, because a vault with no payload has no NUU Flint plugin.

The open step prints the result line of flint open (see below) before the result of flint create. When the launch of Obsidian fails, flint create fails with exit 1 and the code open-failed. The Flint stays, and the next command is flint create --resume '<path>'.

The Obsidian row:

<release> in a row is the release of the run: its target, else the pin, else the recommendation of the CLI build. So a build with the placeholder recommendation (a build before the release cut) also names its release. That build writes no pin, and the row is for example payload 0.7.0 not installed: Release 0.7.0 is invalid: this Flint CLI build carries no recommended release (recommendation.json holds placeholder values). The Flint is ready for CLI work.

The lines below the rows:

When the shards did not install too, one warning names both, for example No network: the shards of the preset blank (flint, orbh) and the Obsidian payload are not installed yet.

An example with no network:

✓ Created the Flint Field Notes
  ...
  Obsidian : payload 0.7.0 not installed (no network). The Flint is ready for CLI work.
⚠ No network: the Obsidian payload is not installed yet.
Next: cd '/home/ada/(Flint) Field Notes' && flint sync && flint open "Field Notes"
Or start an agent: cd '/home/ada/(Flint) Field Notes' && flint sync && flint orbh i

With --json, the result has the fields obsidian (provisioned, existing, skipped, or failed), obsidianRelease, obsidianCause, obsidianChoice, obsidianUnsupported, obsidianIsolated, opened, and openedReady.

flint sync

flint sync installs the release of the pin. It never moves the pin. The row Obsidian payload is part of the step Reconcile content, and it runs after the identity step. A run with nothing to write takes no lock and writes nothing.

A failed or blocked payload row also fails or blocks the step Reconcile content, so the run records no sync time. A failed row gives sync — partial, and a blocked row gives sync — blocked. A pending conversion of a legacy payload completes when the vault is closed. It also completes on an open vault when the NUU Flint plugin of the vault runs and flint sync runs outside that vault: the sync then reloads the vault after the write.

When the recommendation is newer than the pin, a notice says Obsidian payload <new release> is available (pinned <release>). Next: flint obsidian update. The pin does not move.

After the payload row, flint sync completes the pending vault registry changes when no Obsidian process runs. A dry run does not do this step. The step adds the change Completed <n> pending vault registry change(s). A change that waits is a notice: Obsidian runs, so the vault registry change waits. Next: quit Obsidian, then run: flint obsidian vaults repair --yes. Each registry issue prints with its code and its next step. A damaged pending.json names its path: Remove <path>, then run: flint obsidian vaults repair. A registry issue never fails the sync.

flint status

flint status prints one Obsidian line. The line comes from a quick check (presence, type, mode, and size of each release file; no hash), and the read writes nothing. The line wraps to the width of the terminal. A Flint with no id also gets the line. flint obsidian status gives the full facts.

With --json, the field obsidian holds the status model of the quick check. The field obsidianChoice (on or off) stays for 0.7.x, and 0.8 removes it.

flint open and flint open-url

flint open opens or focuses the vault of a Flint. flint open-url does the same for the target of a flint:// URL. The word computer is the Computer Flint of this machine. --no-launch resolves and prints the target without opening Obsidian.

When the vault is closed, Flint does these steps in order:

1. It completes the pending vault registry changes.
2. It installs a missing, pending, or stale payload.
3. It runs the trust check (see Using Obsidian > Open a Flint).
4. The NUU Flint plugin of another open vault opens the vault (open-vault). With the trust setting auto and a passed check, the request asks Obsidian to trust the vault.
5. When no plugin can open the vault, the check passed, and a Computer Flint exists that is not the target, Flint starts Obsidian with the Computer Flint. Then the plugin of the Computer Flint opens the vault with trust.
6. Else Flint launches obsidian://open?path=<path>. A link opens only a folder that the vault registry of Obsidian knows. When the folder has no entry and no Obsidian process runs, Flint writes the entry first. When Obsidian runs, Flint launches nothing and names the step in Obsidian.
7. Flint waits up to 15 seconds for the plugin of the vault.

Flint writes no trust key itself. The plugin of a vault that opens the target sets the trust of Obsidian.

flint setup

flint setup opens the Computer Flint in Obsidian at the end, with the onboarding session. --no-open skips the open. The onboarding session then runs in the terminal. flint setup onboard --no-open does the same for the onboarding session alone. With --json, or with no terminal, flint setup opens the Computer Flint and starts no session. It prints --json: setup starts no session. Start it with flint setup onboard. (or No terminal: …). flint setup onboard --json never uses the terminal for the session.

flint obshn

flint obshn asks the NUU Flint plugin of the vault to open a new terminal tab and to launch flint orbh i <orbh-profile>. It calls the Obsidian manager of the vault directly, so it works while the Flint server is down. -p takes a folder, or a reference as flint open reads it.

flint config

flint config set obsidian on|off writes the machine choice to [obsidian] choice of the Flint CLI config. [obsidian.applied] and the comments of the file stay. flint config set obsidian-trust auto|ask writes the trust setting to [obsidian] trust. ask gives the trust screen of Obsidian for each new vault. Any other dotted key is a nested table: flint config set orbit.devOrigins '[…]' writes devOrigins in [orbit].

The Row of a Vault Registry Change

flint delete, flint move, flint rename, and flint convert print one row for a change of the vault registry. The row is the message, then an indented Next: line when the person must act. A Flint with no vault registry entry gets no row.

flint delete

flint delete refuses a Flint whose vault is open, before it writes anything. Flint also refuses when it cannot prove that the vault is closed. Then it copies the Obsidian backups of the Flint to the scope deleted, also with the machine choice off. A failed copy stops the delete, and the Flint stays. Then it removes the vault registry entry and deletes the folder. With the machine choice off, or on a platform that Flint does not support, there is no open-vault check.

flint move, flint rename, and flint convert

These commands refuse a Flint whose vault is open, before the first write. The message is the message of flint delete. The Next: line is the command itself, for example Next: flint move '<name-or-path>' '<destination>', Next: flint rename '<new name>', or Next: flint convert '<path>' --to <type>. The exit code is 2.

After the move, each command relocates the vault registry entry. The entry keeps its vault id, so the trust of the vault follows the folder. The command prints one row of the vault registry table above. A Flint with no id uses the key path:<canonical folder before the move> for a change that waits.

The Tinderbox Commands

flint tinderbox start, import, remove --move-out, rename (a member, or the box with --tinderbox), and dissolve move member folders. Each checks every member that moves, and it refuses as one unit before the first write:

• One open vault: "<name>" is open in Obsidian. Close it, then run the command again from a terminal outside Obsidian.
• More open vaults: <n> vaults are open in Obsidian: "<name>", "<name>". Close them, then run the command again from a terminal outside Obsidian.

The Next: line is the command to run again, with its arguments and flags, for example flint tinderbox rename <from> <to> or flint tinderbox dissolve --move-to <dir>. An argument with a space or another special character is in single quotes.

After the move, the report has these rows:

flint tinderbox import opens the imported Flint in Obsidian after the move. --no-open skips the open. With the machine choice off, the open is one row: Obsidian: skipped. <message>. Another failure gives the warning The Flint was imported, and Obsidian did not open it: <reason>., then Next: flint open "<name>".

flint tinderbox heal never moves a folder whose vault is open. It keeps the folder and reports it, for example Heal does not move the folder <folder> of <name>: "<name>" is open in Obsidian. The next step says Close "<name>" in Obsidian. Then run from a terminal outside Obsidian: flint tinderbox heal. Heal relocates the vault registry entry of each folder that it moves. A pending change to the old folder follows the folder too.

flint tinderbox check reports a vault registry entry whose folder is gone: The vault registry lists <path>, and the folder is gone. Next: flint obsidian vaults repair.

flint tinderbox sync, heal, and init --from make no vault registry entry. A vault enters the registry when Obsidian opens it, or when flint open writes the entry before a launch by link.

When the box renamed a member, flint tinderbox sync moves the folder of that member and relocates its vault registry entry. An open vault refuses the move: The box renamed "<former>" to "<name>", and "<former>" is open in Obsidian. Nothing was written. The next step is Close "<former>" in Obsidian. Then run from a terminal outside Obsidian: flint tinderbox sync.

Note Templates in the Shard Commands

A shard installs its note templates (otmp-* files) into Shards/(Shards) Obsidian Templates/ for Templater. A note template belongs to the shard, not to the Obsidian payload. When you changed a note template, the install keeps your file and warns:

Kept note template <path>: <reason>. It differs from the note template of <shard>. Next: flint shard reinstall <alias> --replace-note-templates

flint shard reinstall <alias> --replace-note-templates saves a backup of the changed file first. Then it replaces the file: Replaced note template <path>: it had changes. Backup: <backup path>. Using Obsidian explains the steps.

flint migrate run

The local step flint-0.6.0-to-0.7.0-l5 ("Convert the legacy Obsidian payload") converts a legacy payload into the plain install. Using Obsidian explains the conversion.

A waiting conversion is a pending conversion. flint open or the next flint sync completes it. Until then, the line of flint status is Obsidian: conversion to <release> pending or Obsidian: conversion pending, with its next step (see the flint status section above). flint migrate rollback removes the pin that the step wrote. It does not change .obsidian: use the command of the line Undo .obsidian.

Removed Obsidian Commands

A removed command is hidden. A removed subcommand prints one line with the command that replaces it. A removed flag prints the line and a Next: line. Each exits 1. With --json, it prints one envelope with ok: false, the code obsidian_command_removed, the reason, and next.

These flags stay hidden for one release. They do not fail:

flint obsidian dev install <source-dir> is a command of a dev build only. It installs a working tree of the payload source.