On Thu, Mar 1, 2018 at 3:53 AM, Andres Freund <and...@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