Specify a directory for cache

[sQVe]

Hey 👋,

I have my .cache directory set as tmpfs to run all cache related files on RAM. This makes the .cache available only per session which is an issue with bat as the built custom themes I have are removed.

Is there a way to specify a directory for bat to load theme and syntax from? I've tried bat cache --source ~/.local/share/bat but that just creates the cache at that location. I see no option to load the cache from that place.

[eth-p]

The cache directory is determined in this file, and currently isn't configurable outside of setting the XDG_CACHE_HOME environment variable.

It wouldn't be difficult to make it configurable through a command line argument, but if you're looking for a quick and easy workaround:

#!/usr/bin/env bash
export XDG_CACHE_HOME="${HOME}/config"
/usr/bin/bat "$@"

Saving that as /usr/local/bin/bat (with 0755 permissions) should do the trick, assuming bat is installed to /usr/bin.

[sQVe]

@eth-p That would work but I prefer not to touch /usr if possible. I opted for this workaround, in my xinitrc`, until it is configurable via the config or command line:

# Setup bat cache files.
if [[ -f "$HOME/.local/share/bat/themes.bin" ]] && [[ -f "$HOME/.local/share/bat/syntaxes.bin" ]]; then
  mkdir "$HOME/.cache/bat"
  cp "$HOME/.local/share/bat/themes.bin" "$HOME/.cache/bat"
  cp "$HOME/.local/share/bat/syntaxes.bin" "$HOME/.cache/bat"
fi

[eth-p]

That also works, yeah. If you're not adverse to the wrapper idea though, you could add it as a wrapper function in your .bash_profile file instead of as a dedicated executable? It would avoid having to touch /usr, but it comes with the price that other programs which use bat wouldn't use the modified environment variables.

[sQVe]

@eth-p Good point. I'll try that instead.

[eth-p]

Let me know how that works out. If it's still not ideal, one of us could still add a configuration option for it! The only downside would be that you would have to build bat from master or wait for a new release if we go down that route, though.

[sQVe]

@eth-p I would still greatly appreciate if this option was added. I see my current solution and your wrapper idea above as workaround. I have no problem waiting for a release or just building it from source myself.

[neuronull]

Hello, I would like to take this issue if its available.

[neuronull]

Is the desired outcome to be able to specify the cache dir via a command line option?
Is a config file entry sufficient?

My understanding after inspecting the code, is that this cache dir is referenced early on in the processes' runtime and is currently initialized as a member of an immutable lazy_static. Additionally, the cache_dir is referenced in later executions of bat after its been set up. So we would have to store that user-specified cache dir location somewhere, and the config file makes more sense to me than an environment variable.
Am I on track so far? Please correct me if I'm not.

What I'm thinking is we could read the config file first and check for an entry for cache_dir.
As for specifying this in the command line option, could that simply write the cache_dir in the config file?
Or is there even a need for that command line option if the ability to specify it in the config file is there?

[sharkdp]

Is the desired outcome to be able to specify the cache dir via a command line option?
Is a config file entry sufficient?

In bat, every "config file entry" is just a command line option that is implicitly passed to every bat call. As soon as we add a new command-line option, we also have a new "config file entry".

My understanding after inspecting the code, is that this cache dir is referenced early on in the processes' runtime and is currently initialized as a member of an immutable lazy_static.

Yes, that's a problem. We do this because we need to reference the config directory before parsing the command-line options, as the config entries go first (and can be overwritten by command-line options).

An environment variable BAT_CACHE_PATH would definitely work. But to be honest, this whole requests seems like a pretty niche use case. Given that we have an easy workaround, I'm not sure if there is a need to implement this at all. But adding the BAT_CACHE_PATH environment variable probably doesn't hurt.

[neuronull]

@sharkdp Thanks for the insights!
I'd be happy to undertake implementing a BAT_CACHE_PATH environment variable if that is the way forward.

[sharkdp]

Sounds great

[sharkdp]

This has been released in bat 0.13.