Support ignoring the system-wide configuration file

[MatejKafka]

I'm using bat as a portable application, which can be moved between computers and stores all data next to the binary; portable applications should not depend on the configuration of a particular system.

bat supports a user-level configuration file, whose path can be set using BAT_CONFIG_PATH, and a system-wide configuration file stored in C:\ProgramData on Windows, with a fixed path that cannot be changed by the user or disabled (btw, you probably should not hardcode this path, since the ProgramData directory may move; instead, ask the system using SHGetKnownFolderPath).

For the portable scenario (and using a custom configuration file in general), I don't see much value in having multiple layered configuration files, so it should be enough to have a way to prevent bat from using the system-wide configuration file.

I see two ways to implement this feature:

1. Add an environment variable or a command-line argument to ignore the system-wide config, such as BAT_IGNORE_SYSTEMWIDE_CONFIG=1.
2. Ignore the system-wide config when BAT_CONFIG_FILE is set. If a user overrides the user-level config path, I think they would not expect bat to still use the system-wide path, but I might be wrong. :)

I have a minor preference for option 2., but either one is fine with me.

[keith-hall]

and a system-wide configuration file stored in C:\ProgramData on Windows, with a fixed path that cannot be changed by the user or disabled

you could just set the BAT_SYSTEM_CONFIG_PREFIX env var to a non-existing location to disable the system-wide config. I'm not convinced that we'd need another env var for this.
But I agree that hard-coding the path is not ideal.

2. If a user overrides the user-level config path, I think they would not expect bat to still use the system-wide path, but I might be wrong.

Well, the readme clearly states:

If the system wide configuration file is present, the content of the user configuration will simply be appended to it.

So there's no reason for that not to apply just because of specifying a different location for the user config file. I imagine there are use cases where you have machine-level config which you always want to apply and you want to override it differently in different scenarios with different user config files.

[eth-p]

I'm not convinced that we'd need another env var for this.

Adding on to what you said, I don't think environment variables are appropriate for this purpose. It comes across as antithetical to have a program use its environment to decide if it should ignore said environment.

Also: One would have to export the hypothetical environment variable in their shell profile as well, so it wouldn't even be "portable" in the sense that you could run it anywhere and expect the same behavior everywhere.

In my opinion, a portable version of bat would be better achieved as either a build feature or a shell script that sets BAT_CONFIG_PATH and BAT_SYSTEM_CONFIG_PREFIX before running bat.

[MatejKafka]

you could just set the BAT_SYSTEM_CONFIG_PREFIX env var to a non-existing location to disable the system-wide config.

That variable is compile-time only, I cannot set it at runtime.

I imagine there are use cases where you have machine-level config which you always want to apply and you want to override it differently in different scenarios with different user config files.

Fair point.

[MatejKafka]

@eth-p

Generally, there are two types of portable apps:

1. Apps that explicitly support portable mode by e.g. detecting a configuration file in the application directory. This easy to use, but hard to customize in case the user disagrees with the default portable data locations.
2. Apps that are not explicitly portable, but provide ways to override all non-portable paths, either using env vars, CLI arguments, or a config file referenced using one of the other two methods. When these apps are used, the user or the packager typically create a launcher that internally invokes the actual binary and either sets environment variables or passes extra command-line arguments to change the default data paths.

Most systems for packaging portable apps, such as PortableApps.com, portapps, Scoop, and my own Pog have a way to easily generate launchers. Additionally, all of the projects prefer to use existing releases, since building a custom version from source adds complexity, and requires the maintainer to redistribute the binaries, which is against commonly-used proprietary licenses (not an issue with bat).

For these projects, option 2. is preferred, since the packages should have a fixed, consistent structure, which is often not achievable with option 1. For more details about the options for passing the configuration, you might be interested in Section 4 ("Making applications portable") of my thesis (https://matejkafka.com/share/Pog-thesis.pdf).