How to completely uninstall? #1546
Comments
If you look at their screenshot the output is sort of messed up. I personally wasn't aware that atuin provided this feature automatically when pressing the up arrow to go through shell history |
Hmm I see. Probably an altscreen issue from tmux/screen/their terminal/whatever. Fixable with a small config change with most. Annoyingly there's seemingly infinite combinations of setups, so making it work for everyone right out of the box is a game of whack-a-mole. Looks like I can see some vim/some editor output somewhere in there too
Yeah we hear this a lot - mind if I ask which parts of the docs you read for the install? I tried to make sure it's mentioned almost all over, but it's still missed a lot so I'd like to improve that. People feel strongly about the up arrow (both for and against), though there is no consensus as to whether it should be enabled by default or not. |
ellie
added a commit
that referenced
this issue
Jun 4, 2024
From https://axo.dev cargo-dist handles building releases far better than we can, and do so for several large projects now. They also have built an auto-updater We will also need to change our install script to use the cargo-dist installer. Once switched to the new installer, we will no longer be using system package managers wherever possible. If the user wishes to use their package manager, and Atuin is maintained there, then they can choose to do so. This way, we can ensure that users are running a known build, can easily uninstall (just delete the atuin dir), easily update, etc. Builds will use our lockfile, and can have their checksum verified. Later, I'd like to introduce build signing. As Axo are focused on release engineering, they will likely have resolved many more issues than we have - libc versions, etc. I'm not particularly happy with our response of "just use your package manager", as many users seem to have difficulty there. It's unclear what our installer has done, as this behaviour varies massively across systems. It's also unclear how some package maintainers may have patched things Uninstall clarity: #111, #372, #640, #1485, #1546, #2049, #1529
ellie
added a commit
that referenced
this issue
Jun 4, 2024
From https://axo.dev cargo-dist handles building releases far better than we can, and do so for several large projects now. We will need to change our install script to use the cargo-dist installer. Historically, we have used the system package manager wherever possible. Once switched to the new installer, this will no longer be the case. If the user wishes to use their package manager, and Atuin is maintained there, then they can choose to do so. This way, we can ensure that users are running a known build, can easily uninstall (just delete the atuin dir), easily update, etc. Builds will use our lockfile, and can have their checksum verified. Later, I'd like to introduce build signing. As Axo are focused on release engineering, they will likely have resolved many more issues than we have - libc versions, etc. I'm not particularly happy with our response of "just use your package manager", as many users seem to have difficulty there. It's unclear what our installer has done, as this behaviour varies massively across systems. It's also unclear how some package maintainers may have patched things I'm hoping that some better release tooling will lead to more confidence in the process, and therefore more frequent releases. Uninstall clarity: #111, #372, #640, #1485, #1546, #2049, #1529
ellie
added a commit
that referenced
this issue
Jun 4, 2024
From https://axo.dev cargo-dist handles building releases far better than we can, and do so for several large projects now. We will need to change our install script to use the cargo-dist installer. Historically, we have used the system package manager wherever possible. Once switched to the new installer, this will no longer be the case. If the user wishes to use their package manager, and Atuin is maintained there, then they can choose to do so. This way, we can ensure that users are running a known build, can easily uninstall (just delete the atuin dir), easily update, etc. Builds will use our lockfile, and can have their checksum verified. Later, I'd like to introduce build signing. As Axo are focused on release engineering, they will likely have resolved many more issues than we have - libc versions, etc. I'm not particularly happy with our response of "just use your package manager", as many users seem to have difficulty there. It's unclear what our installer has done, as this behaviour varies massively across systems. It's also unclear how some package maintainers may have patched things I'm hoping that some better release tooling will lead to more confidence in the process, and therefore more frequent releases. Uninstall clarity: #111, #372, #640, #1485, #1546, #2049, #1529
ellie
added a commit
that referenced
this issue
Jun 5, 2024
* chore: switch to cargo dist for releases From https://axo.dev cargo-dist handles building releases far better than we can, and do so for several large projects now. We will need to change our install script to use the cargo-dist installer. Historically, we have used the system package manager wherever possible. Once switched to the new installer, this will no longer be the case. If the user wishes to use their package manager, and Atuin is maintained there, then they can choose to do so. This way, we can ensure that users are running a known build, can easily uninstall (just delete the atuin dir), easily update, etc. Builds will use our lockfile, and can have their checksum verified. Later, I'd like to introduce build signing. As Axo are focused on release engineering, they will likely have resolved many more issues than we have - libc versions, etc. I'm not particularly happy with our response of "just use your package manager", as many users seem to have difficulty there. It's unclear what our installer has done, as this behaviour varies massively across systems. It's also unclear how some package maintainers may have patched things I'm hoping that some better release tooling will lead to more confidence in the process, and therefore more frequent releases. Uninstall clarity: #111, #372, #640, #1485, #1546, #2049, #1529 * config * add protobuf * test build * use native arm mac * lol * add toolchain * use 1.78, 2vcpu * nix flake update * 1.77
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm using mac and bash
yesterday I installed atuin, but now the screen is completely broken. I removed atuin via homebrew. but uparrow still blame atuin is not existing.
I searched 'uninstall atuin' on google. and read the https://docs.atuin.sh/. but couldn't find any document about uninstallation.
The text was updated successfully, but these errors were encountered: