Skip to content
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

Allow customizing the location of TLDR_HOME #49

Open
Seirdy opened this issue Dec 17, 2019 · 11 comments
Open

Allow customizing the location of TLDR_HOME #49

Seirdy opened this issue Dec 17, 2019 · 11 comments

Comments

@Seirdy
Copy link

Seirdy commented Dec 17, 2019

Currently, TLDR_HOME is hard-coded in src/tldr.h to point to ~/.tldrc.

It would be nice to configure this location via environment variables or a config file. I personally would prefer to set TLDR_HOME to $XDG_DATA_HOME/tldr to comply with the XDG Base Directory Specification and keep my $HOME clean.

@sebdanielsson
Copy link

Please make this happen!

@gerardbosch
Copy link

Hi there, I think it should be $XDG_CACHE_HOME/tldr instead of $XDG_DATA_HOME/tldr. The "manpages" contained there are cache that can be recreated.

Backup systems will typically ignore the $XDG_CACHE_HOME/ (which defaults to ~/.cache/ if undefined), but not $XDG_DATA_HOME/, as the later should contain user data. Cheers!

@superatomic
Copy link
Contributor

If this feature is ever implemented, this change should also be made to the shell completions in the autocomplete/ directory, as right now they are hard coded to $HOME/.tldrc/tldr/pages/.

@gerardbosch
Copy link

Hi there! Was this finally implemented? I think the bot closed as stale (I don't see a related merge PR or similar).

For anyone interested there's a very performant Rust implementation of tldr that implements Freedesktop.org XDG spec: tealdeer https://github.com/dbrgn/tealdeer
Can be installed with Brew, Nix,...

@MasterOdin MasterOdin reopened this Oct 13, 2022
@MasterOdin MasterOdin removed the Stale label Oct 13, 2022
@andrewcrook
Copy link

as I pointed out here

whilst the tldr c client doesnt use XDG it does look for the following environment variable to store the cache

TLDR_CACHE_DIR

This can be used, for example, to achieve

TLDR_CACHE_DIR=“$XDG_CACHE_HOME/tldrc”

@toxxmeister
Copy link

Slight clarification on the above, TLDR_CACHE_DIR should likely be set to just $XDG_CACHE_HOME (or whatever else you like) since .tldrc/ is created within the specified directory.
If you set the variable to the suggestion above, at best you will end up with $XDG_CACHE_HOME/tldrc/.tldrc/ hierarchy, if $XDG_CACHE_HOME/tldrc/ already exists, or at worst you will entirely disable caching if it doesn't.

@andrewcrook
Copy link

andrewcrook commented Feb 27, 2024

My last comment was a solution was a fudge. Built in XDG support would be better, it still makes sense to have TLDR_CACHE_DIR if you want different from XDG. Depends how it's implemented or reimplemented. You could do the above allowing the user to rename the directory. I don't think having dot file naming convention for files or directories is helpful when already under a dot file or dot directory which XDG paths normally are.

$XDG_CACHE_HOME = $HOME/.config

$XDG_CACHE_HOME/tldrc/.tldrc/
Is just horrible

As is

$XDG_CACHE_HOME/.tldrc/

$XDG_CACHE_HOME/tldrc/
is better ~/.config/tldrc

Don't you think?

@toxxmeister
Copy link

I agree and in fact would prefer to have more precise control or proper adherence to XDG (looking at my XDG dirs, tldrc really is the only one using a dot). My comment above was just clarifying the exact current behavior, since it is (to me at least) a bit unexpected.

In a sense I see three issues here:

  1. TLDR_CACHE_DIR name itself is misleading, since it specifies the directory within which the actual cache directory is created, instead of the cache directory itself.
  2. The cache directory name is hardcoded to .tldrc, which makes it stand out within XDG dirs.
  3. If TLDR_CACHE_DIR doesn't exist, tldr doesn't create the missing directory structure and disables caching altogether.

These three together put you in an awkward position where you either have to set the var to $XDG_CACHE_HOME so that tldr creates .tldrc/ within $XDG_CACHE_HOME/ (which presumably exists), or have to ensure that $XDG_CACHE_HOME/tldrc/ exists, so that tldr can create .tldrc/ within that (which is too much to ask for).

@leomwilson
Copy link

I came across this issue while cleaning up my home directory earlier. It looks like it's still up for grabs so I'll start working on it soon. From my cursory inspection of the code, it seems like it'll be pretty easy to implement XDG compliance, but it'll require a tiny bit of refactoring to avoid the leading dot. I should have a PR later this week.

I read through the discussion on tldr-pages/tldr#1065, and the consensus over there appears to be $XDG_DATA_HOME over $XDG_CACHE_HOME. I'm going to proceed with $XDG_DATA_HOME for now, but that's an easy change if needed. I'll also update the completions to respect $TLDR_CACHE_DIR / $XDG_DATA_HOME.

To maintain backwards compatibility, I'll check for a directory in this order:

  1. If $TLDR_CACHE_DIR is set, use $TLDR_CACHE_DIR/.tldrc (creating the directory if necessary).
  2. If ~/.tldrc already exists, use that.
  3. If $XDG_DATA_HOME is set, use $XDG_DATA_HOME/tldrc.
  4. Otherwise, default to ~/.tldrc.

@superatomic
Copy link
Contributor

I think XDG_CACHE_HOME is the more idiomatic location for caching tldr pages. That directory is for files that can be automatically regenerated if deleted, which applies to these files. XDG_DATA_HOME is for user data, and definitely should not include stuff that is being mirrored from a remote source.

If XDG_CACHE_HOME is unwanted for the reasons listed in the linked issue, I recommend XDG_STATE_HOME, which at least is not meant for user data and is instead for application state, which also applies.

@leomwilson
Copy link

I just looked through the other TLDR clients and those that support XDG base directories overwhelmingly use $XDG_CACHE_HOME. An argument can be made, but I think you're right that cache makes more sense.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

9 participants