Make it XDG compliant

[piegamesde]

Making the extension XDG compliant should be pretty straightforward: Simply replace local datafile=${ZSHZ_DATA:-${_Z_DATA:-${HOME}/.z}} with local datafile=${ZSHZ_DATA:-${_Z_DATA:-${XDG_DATA_HOME:-$HOME/.local/share}/zsh/z}} (not tested).

Implementing it in a backwards-compatible way is a bit less straightforward though: The default file path case needs to check the legacy location in home first and then handle if it exists.

[agkozak]

Thanks for the good idea. I'm going to continue thinking about this one.

I see that there's a proposal to have rupa/z do something like what you suggest.

If rupa/z goes down that path, I will, of course, mimic it -- I like having ZSH-z continue to be a drop-in replacement for it. Let's keep this issue open.

[ratijas]

I wonder, does it make sense anymore to wait for rupa/z to make the first move? Clearly, that project isn't going anywhere at this rate, and even the project owner himself admitted he doesn't use zsh (anymore?)

[agkozak]

I think @rupa has always been solely a bash user; he was kind enough to rewrite his code so that it would work in zsh as well.

I'm sure I'm not the only person who uses both zsh with ZSH-z and bash with rupa/z, and it's nice to have rupa/z use the same database in bash without any extra configuration. I like the idea of having a tidier home directory (which is what I think XDG primarily aims for), but not at the expense of making the inter-operation of the two tools more complicated.

I'd like to leave this issue open and continue to cogitate about it.

In the meantime, remember that you can always set ZSHZ_DATA (or _Z_DATA, if you're using rupa/z as well) to any file you want.

[eugene-reim]

In the meantime, remember that you can always set ZSHZ_DATA

I did it and it doesn't work. I added in .zshrc string ZSHZ_DATA=$HOME/.config/zsh/.zhist and it continues to use the file .z in home

[agkozak]

@eugene-reim Strange -- it works for me. Would you mind posting your whole .zshrc so that I can try to pinpoint what's going wrong? Thanks!

[eugene-reim]

Yep, sure.
zshrc.txt

[agkozak]

In line 93, you have

plugins=(z git sudo zsh-autosuggestions zsh-syntax-highlighting)

z is not my plugin -- that's rupa/z, as packaged by Oh-My-Zsh. If you want to use my plugin, you should follow the instructions here -- you'll want to make sure that you install Zsh-z and change that line to

plugins=(zsh-z git sudo zsh-autosuggestions zsh-syntax-highlighting)

Let me know if that works.

[eugene-reim]

Oh, sorry, I really didn't notice. I'll try it now, thanks.

[eugene-reim]

Yeah it works! Thank you so much and happy New Year btw!

[agkozak]

@eugene-reim Happy New Year!

[bavalpey]

Any updates on this?
You still aren't XDG compliant. Allowing $ZSHZ_DATA to be set to a specific place is not XDG compliant. If it's not set, it must be in the directory pointed to by $XDG_STATE_HOME, and if that isn't set, then it should be $HOME/.local/state (the_ original author of this issue wrote XDG_DATA_HOME, though that is certainly not the right place, as that is not meant for state information like histories)

[agkozak]

@bavalpey

Thanks for your comments and your pull request.

My original reason for hesitating to change Zsh-z's behavior regarding data file location remains the same: my utility still enjoys total interoperability with the original rupa/z, and I still use rupa/z when I use Bash, with the same default data file: ~/.z. I would be very surprised if there are not other people who take advantage of this out-of-the-box, very intentional compatibility.

If we adopt your solution, we please one group of people who value the home directory tidiness that XDG compliance affords, and we allow them to remove one line from their .zshrc (ZSHZ_DATA=/path/to/datafile). In doing so, we would have to admit that we are inconveniencing people who use rupa/z in Bash: unless @rupa also adopts XDG conventions, they will always have to add at least one line of code to their dotfiles to maintain compatibility.

More importantly, though, changing the code is easy, but a seamless rollout of the new behavior is hard to accomplish. People are going to wonder why deleting ~/.z does not clear their z -l readout, or - worse - they will ask why backing up ~/.z did not back up their current database. I think a lot of people would appreciate that I try to avoid making breaking changes like that.

I would like to keep this issue open, because I value the aims of the XDG specification. But I am even more interested in continuing to give my users a smooth and predictable experience.

[bavalpey]

@agkozak
I appreciate the response, and I do very much appreciate the consideration.

There are a few things I want to address.

we please one group of people who value the home directory tidiness

This phrasing is too reductive. There are many advantages of XDG compliance, tidiness is just a small part, and focusing on it makes it seem as though it's just about user preference for organization rather than something that has more meaningful impact. (Of which there are many, tidiness is far from the only— or even the primary—reason for XDG compliance).

In doing so, we would have to admit that we are inconveniencing people who use rupa/z in Bash: unless @rupa also adopts XDG conventions, they will always have to add at least one line of code to their dotfiles to maintain compatibility.

Of course we are slightly inconveniencing them. However, I expect that the vast majority of users of this extension are not regularly using both bash and zsh. Furthermore, of those that are, I would venture to say that they are likely far more likely to be quite comfortable editing their rcfiles and tweaking the two to work together.
In other words, when choosing between two segments of your users to inconvenience, prefer the smaller group. In this case, the smaller group is the set of zsh users that use your extension, also regularly use bash, and also use rupa/z with bash, and also want the histories to be the same. That cutout seems quite small.

More importantly, though, changing the code is easy, but a seamless rollout of the new behavior is hard to accomplish. People are going to wonder why deleting ~/.z does not clear their z -l readout, or - worse - they will ask why backing up ~/.z did not back up their current database.

My PR did have a small migration script for copying ~/.z to the XDG location. This is not the ideal solution, and I fully intended to have there be a conversation with the PR about the best way to do this. In my opinion, the file should be moved, we should inform the user on update, and the user should be told that. However, this would have more substantial impact.

I personally grow quite tired of the nods towards backwards compatibility preventing software from having proper, correct, or reasonable behavior. You can communicate with your users via changelogs. Spit out the changelog in the console when you detect a version upgrade. Spit out a big glaring message that requires affirmation from the user before updating to continue. There's a myriad of ways to do migration without upsetting users.

I think a lot of people would appreciate that I try to avoid making breaking changes like that.

You might ask your users rather than making assumptions. I would always prefer to have well-written software that respects standards.
I wouldn't even classify this as a breaking change.

As a final alternative, you can just detect the presence of the ~/.z file during an upgrade and then keep that as the internal path.

At the bare minimum, new installs of zsh-z should place .z in an XDG compliant location, not in ~

Finally, I want to note that waiting for rupa/z to do anything is unreasonable. The last time that rupa engaged with the repository was December of 2023 (that includes responding to questions/issues). The project can be considered no longer maintained.

---

Another possible solution would be to prompt the user for rupa/z compatibility mode, in which case you either add settings to modify _Z_DATA if it is not overridden by the user's bash profile (trivial to check this, by the way), or just use ${_Z_DATA:-~/.z} as the location.