SQLite Forum

reading databases using a customized virtual file-system
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