SQLite Forum

Wishing CLI could be usefully embedded
Login
Mr. Devienne (sp?), in [a semi-hijacked thread](https://sqlite.org/forum/forumpost/fdc585c712e6e66c?t=h), has described a set of features for the SQLite CLI shell in support of it then being usefully embedded in a larger application, without need of shell source modification.

As somebody working on substantial shell enhancement, I have an interest in enhancements that serve the project purposes and make the shell more useful. So this thread is about one such enhancement, "embeddibility".<sup>a</sup> Features suggested so far include:

\1. Devienne suggests that it be possible to call the shell's REPL<sup>b</sup> and that instead of ever calling "exit()" it just return from that call.

That seems quite easy to do. I have already setup infrastructure to pass "time to quit" up from dispatched commands rather than abruptly ending the process. (This aids cleanup.) Exposing the REPL function and having it always return when .quit or .exit commands are interpreted is a very minor change, and could easily involve some clean preprocessor trickery (if such exists).

\2. Devienne suggests that the shell's main(...) be convertable to something like sqlite3_cli_main().

That would be among the cleanest transformations the preprocessor is made to do.

\3. If the embedding app already uses linenoise, integration would be nice-to-have.

This is not clear, and how that should work is debatable. A separate history for the embedded sub-shell may not be problematic. Linkage and initialization issues are another tangle.

\4. If the embedding app has custom SQLite functions and vtable modules, it might want to pre-register them with the SQLite CLI. So a pure main()-like entry-point is not ideal, in terms of flexibility.

Delegating such functionality to a function replaceable via preprocessing might be workable.

\5. In case the embedding app presents a GUI, with the embedded sub-shell appearing in a dialog, it would be useful for stdin/stdout/stderr streams to be provided by the host application.

A few FILE pointers, set during replaceable initialization should suffice.

\6. Add a .mode to present the table-data in a native GUI-table-widget.

As it happens, among the enhancements I'm developing are pluggable output modes and import varieties. I will think about how such plug-in action might function as an embedding-app-callable function.

\7. ??

Further suggestions in service of embeddibility  are welcome.

----

a. The word "embeddibility" is not yet in common dictionaries, but is used commonly for the concept it obviously denotes.

b. "REPL" => Read, Evaluate, Print Loop

Edited to add points 3+.