rqlite keeps CLI command history between sessions
rqlite 7.13.0 loads and saves interactive command history. The implementation retains recent commands for recall while leaving connection state and execution results outside that history.
An interactive database session often contains queries worth repeating after the terminal closes. rqlite 7.13.0, released on December 15, adds persistent command history to its CLI. The tagged changelog identifies loading and storing that history across sessions as the new feature.
This is a client-side improvement. It retains command text for recall, while the database continues to own replicated state and query execution. I value tools that make a small distributed database straightforward to inspect. Keeping recent queries available removes repetitive typing without requiring the server to grow another stateful subsystem for an interactive client's convenience.
Startup loads commands into the terminal
The CLI entry point creates its terminal and then asks the history package for a reader. If a reader is available and parsing succeeds, it assigns the resulting command slice to the terminal's history. The interactive input loop starts after that setup.
This placement means recall is available through the same terminal history mechanism used during the session. The code does not replay the loaded commands against the database. Reading a history file makes commands available to the user, rather than treating their presence as instructions to execute them again.
The input loop still dispatches commands according to their text. Dot commands such as .tables and .schema use their existing handlers, while SQL follows the query or execute path. Persistence adds continuity to the terminal's input history without changing what an entered command means.
The history file belongs to the local user
On non-Windows systems, the file implementation locates .rqlite_history under the user's home directory. The reader returns no handle if it cannot determine the home directory or open the file. The writer follows the same location lookup and returns no handle if opening fails.
The file is therefore associated with the user running the CLI. Its path does not incorporate the selected database host or port. Commands recalled in another session need to be interpreted against that session's current connection. Persistence of text does not establish that the new session points at the same cluster.
The main program initializes its read-consistency setting to weak and its timer setting to false before loading history. Those are session variables. Loading a previously entered .consistency command into recall does not execute it or restore its prior setting automatically.
That distinction is useful during operational work. A remembered SQL statement and a restored session configuration are different capabilities. This release implements the former, so the user still needs to understand the active connection and settings when choosing to run a recalled command.
Retention filters command text
The history implementation reads the file line by line and filters empty or whitespace-only entries. Writing first removes contiguous duplicate strings and filters blank entries. It then selects the most recent entries up to the configured maximum for serialization.
The distinction between contiguous and global duplication matters. Entering the same command several times in succession collapses into one retained entry. Using a command, then another command, then the first again preserves both separated occurrences. The tagged tests cover that behavior explicitly.
The default maximum is one hundred commands. The history package reads RQLITE_HISTFILESIZE to obtain another numeric size. A nonpositive maximum causes the serialization function to write no commands. The implementation defines a command-count policy, rather than a byte-size limit on the contents of each entry.
Saving happens after the interactive loop
When normal interactive processing ends, the CLI obtains a writer and passes the terminal's history to the serialization function. It closes the writer afterward. The code does not append each command to disk immediately after entry, so an abnormal process termination need not preserve the latest session's commands.
This timing also separates history from an execution journal. The serialized entries do not include the server response, transaction outcome, or a record of which node processed the operation. They provide a recall convenience for the person using the terminal. Server state and request results need their own sources of evidence.
The write path opens an existing file without truncation. Consequently, the selected serialization limit describes the entries passed to the writer, not a strict guarantee that every old trailing byte disappears when a shorter history is written. That implementation detail is relevant when interpreting the on-disk file in this initial release.
I consider the feature useful within that scope. Recent commands can survive an ordinary exit and become available when the CLI starts again. The user can recall a query while still choosing whether it belongs on the currently connected cluster, with the current consistency setting, before submitting it for execution.