Apologies for the slow reply... > Would a better option be to look for the config file under the .config > directory as well as that seems to be a standard location for config > files? What are the conventions for that directory?
Looking under ~/.config is an option as well, but if that route were to be followed, I think following the XDG Base Directory Specification[1] would be more consistent with existing program conventions. The relevant part states: > $XDG_CONFIG_HOME defines the base directory relative to which user specific > configuration > files should be stored. If $XDG_CONFIG_HOME is either not set or empty, a > default equal to > $HOME/.config should be used. I myself set $XDG_CONFIG_HOME to $HOME/config, which allowed me to observe that most applications/libraries rarely hardcode $HOME/.config for their configuration; they read $XDG_CONFIG_HOME first. > How common is it > for this kind of environment variable to be used for this purpose - > you give three examples but I'm not familiar with them and they don't > seem > to follow any pattern - INPUTRC is for the readline library, not a > program, > and I assume that MOST_INITFILE is for the most pager and SCREENRC is > for > GNU screen. Yeah, and it seems very common for applications or libraries to have an environment variable to set for changing the configuration directory, especially if they don't follow the XDG Base Dir Spec. I myself use these env vars in my dotfiles[2] to make applications/programs more "compliant" and my home folder cleaner (I have around 120 lines just to make these programs more XDG Base Dir compliant). Luckily, most programs like NeoVim, Fish, i3, Git automatically Do The Right Thing. With regards to any pattern, to me there just seems to be somewhat common suffixes across env variables these processes consume like 'FILE', 'HOME', 'ROOT', and 'DIR'. Some processes allow for setting the directory where the config is read from, others allow setting the path of the config file itself. I mentioned the INFOKEY_FILE environment variable rather than the XDG Base Dir Spec because I think it would be a bit easier to implement and it would be harder to accidentally make a backwards-incompatable changes. If you wish, I can make a patch for adding support for the INFOKEY_FILE (or whatever name you wish) env variables, or even the compliance w/ XDG Base Dir Spec. Regards, Edwin [1] https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html [2] https://github.com/eankeen/dots/blob/0ec5d03cf3a5ae8411c6bd596cf8fcb818e89b9f/user/config/profile/xdg.sh
