Sure. Two main use-cases to start with.
**First**, embed the SQLite CLI in an existing CLI app, w/o needed source modification.
The *host* CLI app is multi-command (like SVN, GIT, etc...), and uses SQLite databases
already. I'd like to add a *`sql`* or *`sqlite`* command, which embeds the full CLI, so I need
a non-*`main()`* entry-point (e.g. `sqlite3_cli_main(argc, argv)`), and not have that CLI
command ever exit(), but simply return from the entry point.
Note that the CLI has other non-SQLite interactive modes, which can *stack*, I could
enter the SQLite CLI from another interactive-mode, and `.exit` in the SQLite CLI should
just go back to the previous mode. The prompt changes back to that previous mode's one.
Also, the host CLI already uses *linenoise* for CLI-formatting/coloring, so integration would be nice-to-have.
And the CLI has custom SQLite functions and vtable modules it might want to pre-register with the SQLite CLI.
So a pure *main()-like* entry-point is not ideal, in terms of flexibility.
That host CLI is a single-exe, kitchen-sink style, no need for an installer. SQLite or Fossile style :)
Update: And of course, SQLite (the library) is already linked into that CLI app.
**Second**, embed the SQLite CLI in a GUI app, opening in a custom dialog and not a console,
thus not using stdin/stdout/stderr, but having the possibility to have those streams provided by the *host* application.
Here again, calling `exit()` is a no-no, and also needs a non-main() entry-point, like the CLI use-case above.
In this mode, the CLI is meant to use an existing in-memory connection, with lots of virtual tables in it.
SQLite is at the heart of the app, exposing a lot of the state of this large scientific (proprietary) application,
and having the power of the full SQLite CLI app would be great, to troubleshoot/debug that state.
I think the CLI use-case is easily achievable with a few tweaks.
The second is more difficult, and might need the CLI using a VFS to abstract away the IO streams,
or something of that nature. In that GUI-app use-case, being able to add a `.mode` to present the
table-data in a *native GUI-table-widget* would be even better, but that's a different matter and a bit of a stretch goal.
So here you go, this is what I had in mind. FWIW. --DD