Support ignoring the system-wide configuration file about bat HOT 4 OPEN

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.

from bat.

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.

from bat.

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.

from bat.

@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).

from bat.