Thanks for the feedback!
Tbh, it sounds like the fully automated install script is targetting a user that is not you.
Generally I’m trying to make it easier to help and support users that wish to easily work with Atuin, find all the files releated to it, etc. This way, everything related to Atuin can be in one spot, rather than spread across several directories. Cleaning up if you decide you don’t want it is much simpler this way, backing up all Atuin data is easier, etc.
There’s a big divide in users - those that wish to have everything configured in precisely the way they want - perhaps following some freedesktop specs exactly, and those that just want it to work quickly and aren’t fussed.
The fully automated install is targetting the latter group, and the manual/configurable install the former.
For example, before the install script edited .zshrc automatically, I spent heaps of time telling people that they needed to set it up - even though it was in the docs, in several places. I still spend a lot of time telling people that the install script will try to use the package manager, will try to follow specs, etc, so I cannot give a definitive answer as to where things are. Going forwards, the fully automated install script will always do one thing, on every system, and precisely document this. We’re not quite there yet, but will be soon.
If you don’t like that, you can follow the manual steps and get it setup in a way you + your environment are happy with! Generally people that take these steps need much less support.
I think even before this change the script would have caused issues for you, as it edited your .zshrc file automatically too.
Otherwise, specifically about .local/bin. The XDG spec is generally very vague, and inconsistent. It provides env vars for directories such as XDG_DATA_HOME, XDG_STATE_HOME, etc, but it does not provide XDG_BIN_HOME. I’d be more open to supporting it if it did
Progress on this front has stalled: [PATCH] document ~/.local/bin (#14) · Issues · xdg / xdg-specs · GitLab
And actually not the first time the XDG spec has been frustrating - see XDG_STATE_HOME for the location of history data
In general, it’s unclear if users wish us to follow spec to the letter, follow convention, or something else. Hence for the time being, the decision can be left to the user.
We could support XDG_BIN_HOME regardless of what the spec says, or perhaps just ATUIN_BIN_DIR.