New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
eg do not support XDG_CONFIG_HOME #77
Comments
Is |
XDG_CONFIG_HOME is part of XDG directory structure, which is a new (quite old now) specification for unix like systems. The details are are available here. Previously different program used to save the user configuration and data in $HOME folder. This specification tries to unclutter the mess, so that $HOME is more cleaner and config file and data file are having special folder for them. |
Sorry for the delay on this. I've been trying to decide what I think about it. I wasn't familiar with XDG. Trying to get a sense for how widespread this it, it looks like Do you know of other tools that do/don't use it? The I respect the philosophy behind XDG, but I am somewhat hesitant to add (admittedly modest) complexity for what seems like a rather niche case. Certainly XDG users must have some way to support tools that don't look for the XDG directory? I run a symlink script when I install my dotfiles repo on a new machine. Without all tools buying into the XDG system, this step seems unavoidable. Keeping Alternatively, people with XDG could just include an alias in their The I'm curious to hear what you think, though. Looking at those issues, people that use XDG seem to have pretty strong feelings about it. =) |
I'm rethinking my position on this, though I'm considering a slightly different implementation. One thing I notice in your PR is that it looks like you are supporting both the XDG system and the defaults. For example if the XDG directory exists, but the XDG egrc doesn't exist, you still look in the default directory: Is that the way XDG is supposed to work? I would have expected that you have either XDG or |
No, XDG is not supposed to work in tandem with ~. On contrary, it is designed to stop the practice of keeping the config/data file in ~. I have submitted such PR, because, I wanted to maintain the backward compatibility for the users that have used |
Sorry this has taken me so long. I wanted to take a different approach than you did so that I could write tests, but the tests are hard to understand. I'd write them differently if I was writing them now. Can you take a look at this branch and see if it behaves like you expect? It did in my own messing around, but I'd love some confirmation. |
If anybody wanting this and using this directory structure could verify on the branch I mention above, I'd appreciate it. I'm hoping to include this in a release this week, and I'd appreciate a sanity check. |
I just had a look at the branch; I created an eg.conf in $XDG_CONFIG_HOME and it works as expected
Let me know what you think! |
Yikes! Good point on the fact that there should be a subdirectory! I should have realized this, since I've begun using XDG in a few places on my linux machines, but I missed it. Thank you so much for pointing it out! I am inclined to leave it as If I'm wrong about that, please let me know. I use XDG for In the meantime I'll make the change to a directory. Thank you again for taking the time to check, I really appreciate it. |
Well I'm a doofus--I just realized that I had already changed it to |
By all means, egrc is much better! |
I just merged to master looking for Assuming so, I'll likely release a new version next month. |
Yes, everything works as expected. Thanks! |
This is now merged and released as of v1.2.0. |
eg configuration is saved in ~/.egrc. I think eg should support XDG_CONFIG_HOME specification and save its configuration file in XDG_CONFIG_HOME.
The text was updated successfully, but these errors were encountered: