So, once I had it working, there was nothing much to do with it after that. In this case, the tool builds on SSH/SCP and a file format that hasn't changed in the last 20 years (at least). When I commit to write something like this, I try to make sure that it has a scope limited enough so that it can be "completed" or "done". > what is your workflow around maintaining these one off ad hoc "developer boost" type tools? I had to erase some API keys and such a few times, adding `filter` call here. It's really just a wrapper for a few SCP invocations plus a history file (extended) format parser.Ĭhanging servers is just a change in the config file, but it's also helpful for changing jobs, because I can quickly add a bit of filtering before the merging happens. As long as the history file is in the same place (it tends to be on hosts that I setup, and otherwise I check in default locations) and the host has an entry in ~/.ssh/config, the tool will work. > How do you handle maintaining this as you transition through jobs, machines, etc?Ĭurrently, the tool reads ~/.mergerc, which is a JSON file with a list of SSH hosts to SCP history to and from. t, -token string Bugout access token to use for the request tags strings Tags to apply to the new entry (as a comma-separated list of strings) e, -env Set this flag to dump the values of your current environment variables Specify the wrapped command using "-" followed by the command: Wraps a command, waits for it to complete, and then adds the result to a Bugout journal. Hope that helps anyone building similar tools. 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. 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.ĥ. bugout trap also stores data that a program returns from stdout and stderr - this has been INCREDIBLY useful. We use it to keep a record of programs we run in our production environment (especially database migrations).Ĥ. Even we ourselves have very little adoption of that use case internally. We thought that sharing would be useful for teams to build documentation on top of. 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).ģ. This is really useful for programs that use a lot of environment variables. bugout trap has a -env flag which gives users the option of pushing their environment variables into their history. you can use queries like "!#exit:0 #db #migration #prod" to find all unsuccessful database migrations you attempted in your production environment.Ģ. 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. Not trying to push bugout here, but thought Atuin might benefit from some of the lessons we learned:ġ. One of my products, bugout, has a command called "bugout trap". It seems I would have to manually go in and drop rows from the DB if I set up Atuin. 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). Second, I am in awe of how good your documentation is and how well you communicate about atuin to the world at large.ĭoes 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.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |