storytold/photocraft
2
0
Fork 0
mirror of https://github.com/storytold/photocraft.git synced 2026-11-02 18:13:39 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs(cli): installing and generating completions and man pages (#7071)

Browse Source 
Say which packages install them and how to generate and install them
by hand from a checkout. The desktop app has neither.

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
Ivan
2026-10-21 14:58:05 +03:00
parent cb730955f6
commit 8544c98517
2 changed files with 11 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
book/src/automation/cli.md
+10
View File
@@ -73,3 +73,13 @@ bridge mode; the CLI rejects root flags there. See the [MCP launch guide](mcp.md
`mcp` and `serve` fall back to environment variables: `PHOTOCRAFT_CONTROL_TOKEN` and `PHOTOCRAFT_CONTROL_TOKEN_FILE` for the token flags, and `PHOTOCRAFT_CONTROL_PORT` for `serve --port` and `mcp --bridge` (which then bridges to `127.0.0.1:<port>`). The automation roots are flags only: the desktop app's `PHOTOCRAFT_AUTOMATION_READ_ROOT` and `PHOTOCRAFT_AUTOMATION_WRITE_ROOT` grant the CLI nothing. A flag wins over its variable, an empty variable counts as unset, and a bad value is a usage error naming the variable. When `PHOTOCRAFT_CONTROL_PORT` switches `serve` to TCP or `mcp` to bridging, the command says so on standard error. A token together with a token file is a usage error only where a token is read (`serve` on TCP, `mcp` bridging), so a stale exported pair doesn't stop stdio `serve` or headless `mcp`. An automation root given to `mcp` while the variable would switch it to bridging is a usage error too: the roots are the headless engine's, and the bridge would drop them. `<subcommand> --help` lists each variable (unless it is set but empty), never with the token's value. A variable holds a port, so `PHOTOCRAFT_CONTROL_PORT=127.0.0.1:7878` is refused; only `--bridge` takes `host:port`.
This checking is not a security policy layer. Engine commands remain responsible for validating their own parameters.
### Shell completions and man pages
The Linux `.deb` and `.rpm` packages install `man photocraft-cli` (plus a page per subcommand, such as `man photocraft-cli-convert`) and completions for bash, zsh and fish (zsh's in `/usr/share/zsh/site-functions`, which the `.deb` also links from Debian's `/usr/share/zsh/vendor-completions`); the Linux tarball and the FreeBSD tarball carry the same files, the FreeBSD one under `man/man1` and `share/`. The pages list each flag's environment variable, as `--help` does. Without a package, generate them from a source checkout:
```sh
cargo run -p photocraft-cli --example man-and-completions -- out/
```
`out/` then holds `photocraft-cli.bash`, `_photocraft-cli` (zsh), `photocraft-cli.fish`, `photocraft-cli.elv` (elvish), `_photocraft-cli.ps1` (PowerShell) and the `.1` man pages. For example, copy `photocraft-cli.bash` to `~/.local/share/bash-completion/completions/photocraft-cli`, `photocraft-cli.fish` into `~/.config/fish/completions/`, `_photocraft-cli` into a directory on zsh's `$fpath`, and read a page with `man -l out/photocraft-cli.1`. The desktop app `photocraft` has neither.