On Thu, Mar 1, 2018 at 3:53 AM, Andres Freund <andres@anarazel.de> wrote:
>
> On 2018-01-12 09:53:51 -0500, Curt Tilmes wrote:
> > The convention widely adopted for this type of thing is to allow
> > multiple config files to be in a directory, usually the '.d' version of the config filename.
> > What do you think?
>
> Seems like a reasonable idea to me.
Thank you for reviewing!
> This is already pretty crufty, can't we make this look a bit prettier,
> rather than extending this approach?
My goal was to match the surrounding code style, so I simply copied
existing lines. I
think most of your comments (crufty, ugly) stem from the existing
code, not the patch. I also
wanted to minimize any impact on the existing well-tested, deployed
code, just adding this
tiny bit of new functionality. I'd rather not rewrite the existing,
working code just to make it
pretty.
Do you have any specific suggestions? Would it help if I separated
the new code into its own
subroutine?
> So there's no really well defined order in which we parse these?
These are after the existing homedir/sysconfdir, but yes, once we fall
down to the '.d' directory,
we just keep trying until we find the specified service, and fail if
we never find it.
> In my experience with such .conf.d directories it's very useful to
> filter names not matching a common pattern. Otherwise you end up with
> editor tempfiles and such being used, which gets confusing.
Suggestions? I'll make it skip over files prefixed with '.'.
Anything else you suggest?
Thanks,
Curt