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