> ...and also, for your own and the operator's sanity, skip anything > else beginning with '.',
Not sure I agree with that; I'd have to think about it. I could argue it either way. Why do you think .-prefixed entries should be skipped? Relatedly, do you feel the same way about names beginning with, or containing, other unusual things, such as , + | ~ # * % !? Why or why not? > names that don't end in ".conf" (or ".inetd" or whatever you think > the proper suffix should be), Yes. > and anything that isn't a regular file (DT_REG). I don't recall whether this is relevant (it's been quite a while since I did anything with d_type), but I strongly believe that symlinks should be followed before any such test. > (If you get DT_UNKNOWN it's reasonable to call stat to get the real > type rather than just skipping it, and you might want to allow > symlinks, but definitely skip directories, devices, named pipes, > etc.) I'm not sure I agree. (I'm also not sure I disagree.) I certainly don't have any immediate use for any such, but I'm also very unsure this wouldn't be a case of forbidding stupid things and thereby forbidding clever things. Maybe a switch to turn it off, or maybe people who want to get that clever should just hack on the source themselves? I'm not sure how reasonable I think that is. If such a check does go in, well, I don't *think* O_PLAIN (fail if the putatively-opened object isn't a plain file) dates back far enough I got it into NetBSD's tree, but if there isn't currently anything equivalent, maybe it'd be worth adding? I found it borderline trivial to add, and it really helps for things like this. I should probably go read man.netbsd.org's open(2).... > ...also I strongly recommend against having global settings that are > meant to change around as things are included (such that the order > includes are processed in matters) -- you wouldn't write code that > used global variables that way, don't do it in configs... I may - occasionally - write code that uses global variables that way, depending on precisely what you mean. I definitely think there is a place for (to borrow from the current syntax for a moment) 10.10.10.10: .include "private-stuff/" 20.20.20.20: .include "world-facing-stuff/" *: .include "everybody-stuff/" This may or may not be an example of what you're talking about. I do think the order in which the directory entries appear in the directory should not matter; either the spec should be such that the order in which they're processed doesn't end up mattering, or the entries should be sorted in a well-defined order (whether hardwired or chosen by the admin or indicated by the include directive or what). /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
