cat: Allow 'bat' to find existing configuration

[danielbayley]

• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same change?
• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you written new tests for your changes? Here's an example.
• Have you successfully run brew style with your changes locally?
• Have you successfully run brew tests with your changes locally?

---

Following #6504, setting HOMEBREW_BAT to anything enables the use of bat in place of cat. But because of the environment variable filtering, it is unable to recognise user configuration either exported as BAT_* environment variables, or a configuration file at $XDG_CONFIG_HOME/bat/config.

The simplest solution, as currently implemented in this PR, is to just set HOMEBREW_BAT to the path of the configuration file. For example export HOMEBREW_BAT=$XDG_CONFIG_HOME/bat/config. Although, if Homebrew didn't filter XDG_*_HOME variables from the environment, bat would work as is, as well as being be a more general solution.

Alternatively, Homebrew could avoid filtering BAT_* environment variables.

[MikeMcQuaid]

What are the list of bat environment variables that you personally need/use? I think it may be worth just having HOMEBREW_BAT_WHATEVER variables which we then set to BAT_WHATEVER when bat is run.

[danielbayley]

What are the list of bat environment variables that you personally need/use? I think it may be worth just having HOMEBREW_BAT_WHATEVER variables which we then set to BAT_WHATEVER when bat is run.

Personally, either most of them (BAT_STYLE, BAT_THEME, BAT_PAGER etc…) or none of them, depending on whether I use a config file or define them in my .zshrc, which kind of depends on the accepted implementation of this PR… I'm not particularly keen on the solution being to duplicate each one and prefix with HOMEBREW_… Allowing bat to find the configuration seems better, if passing through BAT_* variables is not an option. Or, would simply allowing XDG_*_ variables to pass through not be the best solution? @MikeMcQuaid

[MikeMcQuaid]

Allowing bat to find the configuration seems better, if passing through BAT_* variables is not an option.

Can that be defined with an environment variable?

Or, would simply allowing XDG_*_ variables to pass through not be the best solution?

No, we definitely don't want to allow them to be passed through as they are likely to affect formula builds. We could consider copying them to HOMEBREW_XDG_* variables and then setting them back just for bat if it cannot find it's configuration otherwise.

[danielbayley]

Can that be defined with an environment variable?

Yes, BAT_CONFIG_PATH, which this current implementation uses…

We could consider copying them to HOMEBREW_XDG_* variables and then setting them back just for bat if it cannot find it's configuration otherwise.

However this suggestion sounds like a better/more general solution; I'll see if I can remodel the PR around that approach… @MikeMcQuaid Where in the codebase is the environment filtering happening?

[MikeMcQuaid]

However this suggestion sounds like a better/more general solution; I'll see if I can remodel the PR around that approach…

I'd rather the opposite: let's scope it back to just BAT_CONFIG_PATH, add HOMEBREW_BAT_CONFIG_PATH to env_config.rb, update

brew/bin/brew

Line 65 in e1f3b0b

for VAR in BROWSER DISPLAY EDITOR NO_COLOR PATH

and add ENV["BAT_CONFIG_PATH"] = Homebrew::EnvConfig.bat_config_path in cat.rb (and also in the cask one, if desired).

[danielbayley]

I'd rather the opposite: let's scope it back to just BAT_CONFIG_PATH

@MikeMcQuaid The problem with that previous approach is it still imposes limitations on bat, as it can't read user syntaxes/language definitions and themes under $XDG_CONFIG_HOME/bat/*, and $XDG_CACHE_HOME/bat/*. This latest commit implements the HOMEBREW_XDG_*_HOME variables, and everything now works as if bat was called independently.

[MikeMcQuaid]

As mentioned: I'd rather we kept this bat specific. The XDG variable version people are going to expect to work for more than just brew cat.

[MikeMcQuaid]

Let's use bat-specific, non-XDG variables. Will consider a follow-up PR that handles XDG correctly across the entire codebase.

[danielbayley]

The XDG variable version people are going to expect to work for more than just brew cat.

Right so it's potentially a more general solution… why is that a bad thing?

Where else does brew optionally use other utils like bat?

Let's use bat-specific, non-XDG variables.

There are more BAT_* variables to manage than the 3 XDG ones… and they still aren't enough to mitigate the limitations imposed by blocking XDG_*_HOME… are you sure?

Will consider a follow-up PR that handles XDG correctly across the entire codebase.

@MikeMcQuaid How would that differ from this approach?

[MikeMcQuaid]

Right so it's potentially a more general solution… why is that a bad thing?

General solutions are good when they work generally. In this case it's a general solution that affects a single option on a single command.

Where else does brew optionally use other utils like bat?

I can't tell you off the top of my head what other tools Homebrew calls out to that support XDG_* arguments, I'm afraid, because I don't and have never used them.

There are more BAT_* variables to manage than the 3 XDG ones… and they still aren't enough to mitigate the limitations imposed by blocking XDG_*_HOME… are you sure?

We're not trying to be exhaustive here. To be honest, I'm already starting to question the value of adding this much code to support something only one person has asked for.

@MikeMcQuaid How would that differ from this approach?

It would involve passing through XDG_* more consistently and removing it in all cases we now it will cause problems e.g. install, etc.

[MikeMcQuaid]

@danielbayley any news/thoughts on the above?

[danielbayley]

@danielbayley any news/thoughts on the above?

We're not trying to be exhaustive here.

@MikeMcQuaid Sure… Well it seems to me we should either support bat, or not. Half implementing it (in #6504), but then crippling it's features seems pointless… why even add it in the first place?

It would involve passing through XDG_* more consistently and removing it in all cases we know it will cause problems e.g. install, etc.

Will consider a follow-up PR that handles XDG correctly across the entire codebase.

I think this is the proper approach. I'll take a look at implementing it… Where specifically are XDG_* and other variables being filtered out, is it just bin/brew and Library/Homebrew/env_config.rb?

[MikeMcQuaid]

but then crippling it's features seems pointless… why even add it in the first place?

Because it works fine for me (and others) without configuration. As we can't agree: passing on this for now, sorry.

Where specifically are XDG_* and other variables being filtered out, is it just bin/brew and Library/Homebrew/env_config.rb?

bin/brew. They will need to be set to HOMEBREW_XDG_*, documented and set back on subcommands where it makes sense (notably: not brew install).

[danielbayley]

As we can't agree: passing on this for now, sorry.

@MikeMcQuaid But I last pushed the exact changes you requested here:

I'd rather the opposite: let's scope it back to just BAT_CONFIG_PATH, add HOMEBREW_BAT_CONFIG_PATH to env_config.rb, update

brew/bin/brew

Line 65 in e1f3b0b

for VAR in BROWSER DISPLAY EDITOR NO_COLOR PATH

and add ENV["BAT_CONFIG_PATH"] = Homebrew::EnvConfig.bat_config_path in cat.rb (and also in the cask one, if desired).

[danielbayley]

bin/brew. They will need to be set to HOMEBREW_XDG_*, documented and set back on subcommands where it makes sense (notably: not brew install).

Ok, I'll take a look when I can…

@MikeMcQuaid Just as an aside, my motivation here is that I have a homebrew-dotfiles tap as my dotfiles, and then set XDG_CONFIG_HOME to brew --repo $GITHUB_USER/dotfiles. It's an elegant solution for me… but it's a bit of a pet peeve when lazy development practices (not implying that of Homebrew) force users to just shove everything in $HOME/.junk.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[danielbayley]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

@MikeMcQuaid Is this not ready to merge?

[MikeMcQuaid]

Sorry for the delay, thanks for the PR and patience @danielbayley!