On 2025-05-23, Thomas Passin <li...@tompassin.net> wrote: >> Alternatively look at the PATH envronment variable, which >> contains a list of directories separated by semicolons and which you can >> access as os.environ['PATH'] . > > There is really no reason for a config file to be on the system > path.
On Unix/Linux I would _never_ expect a config file to be in the PATH. PATH is for executables. Executables and config files are not stored together. That's simply not how it's done on Unix. There is sort of a traditional set of locations where applications look to find a config file: $HOME/ $HOME/.config/ $HOME/.config/<appname>/ /etc/ /etc/<appname>/ /usr/local/etc/ /usr/local/etc/<appname>/ <location specified by command line argument> <location specified by ENV variable> The last two overried all of the others. Config files that reside in $HOME/ usually start with a dot. Often they end in 'rc'. Config files in other directories usually don't start with a dot. There's usually an <appname> directory only when an app needs multiple config files. If an app only has one config file, tradition is that you don't need a directory for it. Many applications will parse two config files: a global one from /etc or /usr/local/ and a user-one from somewhere under $HOME. However, it varies a lot from one application to another... > On Windows, if it's not in the program's home directory (or a subdir > of it), then it's common to be in the user's home directory. That's > assuming the program is expected to have possibly different > configurations for different users. > > Otherwise there's a \Users\Public directory (or [...] > > The most flexible plan would be to have the program look in all > those likely places for its config file. For more flexibility - but > this is unnecessarily complicated for many applications - have the > program look first on the command line for the config directory, > then for an environmental variable, then in those likely places. -- https://mail.python.org/mailman3//lists/python-list.python.org
