Weekly release 2024.19

[ellie]

Testing release for the 19th week of 2024

Caveats

This is a pre-release, and is not as tested as a production build

1. It may not always be easy and without manual steps to downgrade from a weekly build to the last stable. It will be possible to upgrade automatically to the next stable after a weekly.
2. Weekly builds are more likely to contain bugs or regressions. They are unlikely to lose data, but do be cautious when running the bleeding edge.
3. Weekly builds may contain functionality not yet in a production release. Please let us know what you think!

Download

You can download binaries here: Release · atuinsh/atuin@ce67e52 · GitHub

Download, extract, and put atuin somewhere in your PATH.

Alternatively, run

cargo install --git https://github.com/atuinsh/atuin atuin --tag weekly

Note: you will now require the protobuf compiler to be installed on your system to build from source. This can be installed with

brew install protobuf

on macOS, and

apt install -y protobuf-compiler

on Debian/Ubuntu/similar.

Read more here

Changes

feat(daemon): add support for daemon on windows (#2014)
fix: add incremental rebuild to daemon loop (#2010)
fix: add protobuf compiler to docker image (#2009) 
feat: add background daemon (#2006)
fix(config): add quotes for strategy value in comment (#1993)
fix: adapt help to `enter_accept` config (#2001)
feat(ui): scroll history infinitely (#1999)
chore(deps): bump serde_with from 3.7.0 to 3.8.1 (#2002)
chore(deps): bump serde_json from 1.0.115 to 1.0.116 (#2003)
chore(deps): bump lukemathwalker/cargo-chef (#2004)
fix(dotfiles): allow clearing aliases, disable import (#1995)
refactor: preview_auto to use enum and different option (#1991)
chore(deps): flake.lock: Update (#1992)
feat(history): create atuin-history, add stats to it (#1990)
feat(ui/dotfiles): add vars (#1989)
chore(deps): bump rustix from 0.38.32 to 0.38.34 (#1986)
chore(deps): bump unicode-width from 0.1.11 to 0.1.12 (#1987)
chore(deps): bump debian (#1988)
perf(nushell): use version.(major|minor|patch) if available (#1963)
chore(deps): bump typed-builder from 0.18.1 to 0.18.2 (#1967)
chore: add some more debug logs (#1979)
feat(dotfiles): support syncing shell/env vars (#1977)
fix(ci): release workflow (#1978)

Testing

For now, alias importing has been disabled. There are too many issues with certain shell configs, and I need a reliable way of executing a command and getting the output in an interactive shell session. I’m currently seeing what I can do with a pty, and how any extrenuous output can be trimmed

Syncing shell/env vars

Along with aliases, we can now sync global env or shell vars. These can be set with a similar interface to aliases

atuin dotfiles var set <NAME> <VALUE>

By default, this will export the var. If you would not like to export it, pass --no-export, or -n

Vars can be listed

atuin dotfiles var list

or deleted

atuin dotfiles var delete <NAME>

Here are some of mine, for example

I’d like to formalize workspaces a little more in the future (beyond just a filter on search), so scoping vars and aliases by workspace would be a pretty cool thing to have.

Daemon

Discussed a bunch in the daemon thread, but Atuin can now sync with a background daemon. A long time ago I decided to sync in a forked process after the command completes - this was to avoid complexity, and I thought it would be Good Enough.

It has been! However, there has been issues with certain filesystems, and this method requires that we write to sqlite before any commands can run. In order to minimize any possible latency there, the daemon runs everything in the background.

It also means that sync is not tied to shell activity. Remote machines can have your full history and up-to-date dotfiles from the second you ssh into them (next: realtime?)

To configure the Atuin daemon:

[daemon]
## Enables using the daemon to sync
# enabled = false

## How often the daemon should sync in seconds
# sync_frequency = 300

## The path to the unix socket used by the daemon (on unix systems)
## linux/mac: ~/.local/share/atuin/atuin.sock
## windows: Not Supported
# socket_path = "~/atuin.sock"

## The port that should be used for TCP on non unix systems
# tcp_port = 8889

You’ll then need to run atuin daemon somewhere. I currently have it in a tmux session, with ATUIN_LOG=info atuin daemon. The intent is for this to end up as a systemd unit/similar, however for now I’d like to keep it as simple and visible as possible. We’ll probably have some sort of integration to automatically set up the services on most platforms.

[Adda]

atuin dotfiles var needs a clear subcommand, similarly to atuin dotfiles alias clear. Otherwise, working with env vars seems to be working as expected. Daemon runs well, too.

The obvious problem is that having the daemon set up in the config and not running the daemon causes errors. I am wondering whether there should be a fallback to the original approach when a daemon for whatever reason fails (daemon is not running etc.) while being activated in the config, instead of printing errors. Print these errors only as a logging information, for example? Not sure what the best approach would be.

[ellie]

@Adda

atuin dotfiles var needs a clear subcommand

Is there a reason for this, other than parity with the alias command? Just thinking of an actual use case.

I think if the daemon is not running, we should error every single time. Otherwise Atuin will not record history, which shouldn’t be silent. I don’t think falling back to the old approach would work either - if the user is on ZFS for instance, their shell will suddenly become slow with no explanation.

Realistically, we will soon be starting the daemon for users automatically. So it won’t be as large a problem

[dunxen]

Yay, the daemon has solved the issues I’ve been having using btrfs!

Thank you <3

[Adda]

@ellie

@Adda

atuin dotfiles var needs a clear subcommand

Is there a reason for this, other than parity with the alias command? Just thinking of an actual use case.

Partly for the feature parity, but mainly because this is what I think one would expect. I know I expected clear subcommand to be present. I image the workflow would be for many people similar to this:

1. Install Atuin. Aha, Atuin has some kind of dotfiles synchronization feature.
2. Start experimenting with the env vars. Add a few env vars, open a few terminals. See that it works (even workspace-specific env vars and aliases some day, for example).
3. OK, this is neat. Time to set it up for the serious work now. Let’s start anew with a clean state. Oh, I played with all those dotfiles settings, but in order to start using them for real, I have to manually remove all of them one by one? With clear, it would be just dotfiles alias clear and dotfiles var clear.
4. Alternative: OK, I do not like this. Let me get rid of all the dotfiles settings. Oh, I have to do it manually?

Since Atuin dotfiles modify the shell configuration, there should always be a quick reset to a clean state with no modifications to the user’s shell, in my opinion.

@ellie

I think if the daemon is not running, we should error every single time. Otherwise Atuin will not record history, which shouldn’t be silent. I don’t think falling back to the old approach would work either - if the user is on ZFS for instance, their shell will suddenly become slow with no explanation.

You are probably right. There should not be that many cases where for whatever reason a daemon fails to run. It may fail to sync across the internet, but that should not be an issue for its local-oriented functionality.

[ellie]

In that case it totally makes sense, thanks!