First of all, great name.
Second, I am in awe of how good your documentation is and how well you communicate about atuin to the world at large.
Does Atuin offer any features to toggle the capture of commands into its DB? Being able to opt-in or opt-out of Atuin history on a per-command basis would be pretty useful, especially because there is also the atuin sync feature.
I usually work with sensitive information inside a tmux session because, in the default bash configuration, most commands run in tmux never make it into bash history (I believe the last pane to exit is the only one that does make it). It seems I would have to manually go in and drop rows from the DB if I set up Atuin.
One of my products, bugout, has a command called "bugout trap". Not trying to push bugout here, but thought Atuin might benefit from some of the lessons we learned:
1. Because bugout trap is opt-in (you have to explicitly prefix your command with "bugout trap --", it also allows users to specify tags to make classifying commands easy. This is really useful for search - e.g. you can use queries like "!#exit:0 #db #migration #prod" to find all unsuccessful database migrations you attempted in your production environment.
2. bugout trap has a --env flag which gives users the option of pushing their environment variables into their history. This is really useful for programs that use a lot of environment variables. The safest way to use this is to first trap commands into your personal knowledge base with --env, then remove or redact any sensitive information, and only then share (in case you want to share with a team).
3. We thought that sharing would be useful for teams to build documentation on top of. Even we ourselves have very little adoption of that use case internally. We use it to keep a record of programs we run in our production environment (especially database migrations).
4. bugout trap also stores data that a program returns from stdout and stderr - this has been INCREDIBLY useful. I do want to add a mode that makes the capture of output optional, though, as currently bugout trap is unusable with things like server start commands which run continuously.
5. In general, I have found that command line history is very personal and private for developers so collaborative features are going to rightly be seen with skepticism.
Hope that helps anyone building similar tools.
$ bugout trap --help
Wraps a command, waits for it to complete, and then adds the result to a Bugout journal.
Specify the wrapped command using "--" followed by the command:
bugout trap [flags] --
Usage:
bugout trap [flags]
Flags:
-e, --env Set this flag to dump the values of your current environment variables
-h, --help help for trap
-j, --journal string ID of journal
--tags strings Tags to apply to the new entry (as a comma-separated list of strings)
-T, --title string Title of new entry
-t, --token string Bugout access token to use for the request