[lewo]

The main issue is to use configuration files residing somewhere in the filesystem. This looks like a global variable in a codebase (something we generally try to avoid). Instead, the configuration file should be explicitly provided as a command line argument. Systemd sandboxing can also be useful to ensure the program only uses the expected set of files.

For instance, on my NixOS machine, the Nginx configuration is not in `/etc/nginx` but explicitly provided and can then be known with ps:

$ ps aux | grep nginx

nginx: master process /nix/store/9iiqv6c3q8zlsqfp75vd2r7f1grwbxh7-nginx-1.24.0/bin/nginx -c /nix/store/9ffljwl3nlw4rkzbyhhirycb9hjv89lr-nginx.conf

[Karellen]

> This looks like a global variable in a codebase (something we generally try to avoid).

Aren't they more like global constants than variables? Loaded at startup, and never change during that run of the program. (With the exception of only explicitly being re-read on SIGUSR1 for daemon-like programs.)

And global consts, or #defines, or whatever, are things we generally don't try to avoid?

[ris58h]

It's not a bad idea but it's not applicable to every piece of software. I don't think that passing a config file for every git command would be convenient.

[viraptor]

You can change the commandline string at runtime. You could inject a fake "-c correct/path" even if it's not there. (That's useful for other things too, like injecting the git revision of the app into the commandline)

[jamann]

How long does it take you to type out that path?

[em-bee]

/nix/store/9ii<tab>nginx.conf