Weekly release 2024.08

Here we are with the first weekly release :partying_face:

As discussed here: Pre release testing

Feel free to discuss here, or on the #testing discord channel:

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

I’ve decided to not create a GitHub release for these. I don’t 100% trust the release infrastructure that may have been setup elsewhere to handle pre-releases properly, and I’d rather not alert those watching releases with unstable builds.

Plus, if I’m going to choose a single canonical place for these, I’d rather use a forum post.

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

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

Alternatively, run

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

Changes

This release does not require self hosted servers to upgrade, and has no server-side changes.

fix(bash): rework #1509 to recover from the preexec failure (#1729)
fix(xonsh): Add xonsh to auto import, respect $HISTFILE in xonsh import, and fix issue with up-arrow keybinding in xonsh (#1711)
fix: fish init (#1725)
feat: support syncing aliases (#1721)
feat: add 'ignored_commands' option to stats (#1722)
feat(search): process Ctrl+m for kitty keyboard protocol (#1720)
fix(ui): don't preserve for empty space (#1712)
feat: Add xonsh history import (#1678)
perf: optimize history init-store (#1691)
feat: Add 'a', 'A', 'h', and 'l' bindings to vim-normal mode (#1697)
docs: minor formatting updates to the default config.toml (#1689)
feat: use ATUIN_TEST_SQLITE_STORE_TIMEOUT to specify test timeout of SQLite store (#1703)

Testing

History store init

With the sync v2 release, we sometimes prompt users to run atuin history init-store. This was reported by some users to be fairly slow.

I’ve done a bit of optimizing here (mostly around sqlite transactions). If you have not yet switched to sync v2, or have some other machines to add, please let me know if the store init feels fast or fails.

Xonsh

If you have access to a machine that’s used Xonsh, testing the Xonsh history import would be fantastic.

Aliases

This does not yet support NuShell

Otherwise, I’ve added a feature that should sync shell aliases. This is not yet incorporated into statistics, but should allow us to de-alias them.

Make sure you’re using sync v2

To add an alias name=value, run

atuin config alias set name value

You can run this several times with different values to overwrite aliases. To delete an alias, run

atuin config alias delete name

If you reload your shell, the alias should be set!

I’d like to support syncing more environment setup and dotfiles in the future, so am open to discussing this further.

1 Like

Hello. I am running the commit 3d82adad369c47ab99b6fa87dba8797150065b73, compiled and installed with cargo installl --path .. Running Zsh.

Atuin works as normal without changing anything.

Adding aliases already existing in your shell and removing them produces the following situation:

.zshrc:
alias j=just

$ atuin config alias set j just
# Reload shell / Launch a new shell.
$ j
zsh: command not found: j
$ atuin config alias delete j just
# Reload shell / Launch a new shell.
$ j
zsh: command not found: j

Now I cannot run j in any state. Surprisingly, I did the same with lg=lazygit first, and it behaved the same, but for some reason it fixed itself after trying to randomly run set and delete subcommands. But for j=just and m=make (all of them already existing aliases in my Zsh config), the command not found error remains.

Creating completely new aliases, running them, and removing them again works as expected.

Both setting and deleting aliases should produce some additional info:
$ atuin config alias delete <nonexistent alias> should produce an error message and fail, and
$ atuin config alias set j just; atuin config alias set j just2 should notify the user about resetting the alias.

I would want atuin config alias list (and in the future some TUI or at least some config file or similar, too) to list the currently handled aliases. When the commands to set and delete do not produce any info such as atuin alias: Redefining alias 'j' to 'just' and atuin alias: Deleting non-existent alias 'j', I quickly lost control over which aliases I currently have set and which are not set.

Is it possible to make more complicating aliases, such as aliases for subcommands? E.g., gc=git commit. Something like atuin config alias set gc "git commit"?

I’m currently unable to replicate this one :confused: Are you sure that the cargo install Atuin is first in your path?

So far for me, adding an existing alias to Atuin overwrites it. Deleting it reverts to the old alias.

You can confirm this behaviour by running atuin init zsh and checking that it contains the alias definition.

Totally makes sense, I’ll make some QoL improvements

Yep, it works just as you say :smiley:

This is great both for the list of aliases for now, and for debugging the issues. And it actually revealed the issue I had above. At some point, I had to have messed up the order of alias name and its corresponding command and created cyclic aliases, even though I thought I removed them afterwards. This is what Atuin initializes the Zsh config with currently:

# ...
alias m='make'
alias make='m'

Removing the appropriate aliases fixes the above-mentioned issue. False alarm :smile: Everything now works as expected.

Great. Looks good to me.

Out of curiosity, what did you mean by this? I have Atuin installed only through cargo which gives the appropriate binaries in my PATH.

$ cargo install --list
atuin v18.0.1 (/home/adda/documents/it/atuin/atuin):
    atuin

Furthermore, I think I would like to be able to apply these set aliases to atuin stats and possibly in the commands suggestions (showing the actual command run in the history list, but maybe if the command is an alias, also show the alias value somewhere to the right on the line, for example), but not add the aliases to the shell configuration. That might be actually useful if one forgets some elaborate alias. No need to run which elaborate_alias to see what it was aliased to.

I’ve just added atuin config alias list, and feedback for all existing commands. Set will now alert you if you’re overwriting an existing alias. Might also be worth adding cycle detection :thinking:

PR: feat: add alias feedback and list command by ellie · Pull Request #1747 · atuinsh/atuin · GitHub

It’ll be released as a weekly on ~Monday :slight_smile:

I’ve seen a few issues where people have multiple versions of Atuin installed at once. This leads to weird issues, and given Weeklys haven’t been around for long I wanted to rule it out

I agree! It’s definitely on the plans. Just need to figure out a nice way of doing it, and decide if aliases should apply to historic data too (should we assume pre-alias history that matches the alias should be expanded?)

All great news. I will update now on the latest master and see how it all goes.

Ah, totally makes sense. Then the order of paths in your PATH would matter.

Out of the blue, I would say yes, but I do not know what kind of issues that might bring. It will be always easier, I presume, to just expand the new commands where you 100 % know you want to expand them.

All seems to run well.

Just a nitpick would be to separate the alias values and possibly even the alias names with ticks or something to highlight where they begin and end. Something like the following:

$ atuin config alias set m "make run"
# Change this:
Overwriting alias m=make with m=make run
# to something like this:
Overwriting alias 'm=make' with 'm="make run"'.

I made a PR for that. Feel free to close the PR if you do not agree.

1 Like

Glad it’s working!

I’ve merged the PR, thank you!

A post was merged into an existing topic: Weekly release 2024.09

Closed in favour of the latest weekly: Weekly release 2024.09