On 21-01-31 18:12, David Holland wrote:
| Alternatively you could put the glob in the include explicitly
| (that is, "include dir/*.conf"
That seems the sanest to me too; it's explicit, and it's also
following a well-established pattern used by other applications,
including: dovecot, (apache)
Date:Sun, 31 Jan 2021 18:12:21 +
From:David Holland
Message-ID:
| Basically what you want is to read only files matching some glob that
| matches the POLA reasonably well, like "*.conf".
No, what I want is for it to read the files that are there, whatever
t
> The reason to have a suffix and only read files with that suffix is
> that there are lots of ways to get extra files in the directory that
> the user didn't mean for you to read, and ~98% of the time they won't
> have the right suffix so filtering by suffix is a good way to skip
> them and avoid
On Wed, Jan 20, 2021 at 01:37:44AM +0700, Robert Elz wrote:
> Date:Mon, 18 Jan 2021 22:15:30 +
> From:David Holland
> Message-ID:
>
> | ...and also, for your own and the operator's sanity, skip anything
> | else beginning with '.',
>
> That one is pr
>>> 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.
> That makes not much sense, the d_type tells you it is a s
Date:Mon, 18 Jan 2021 22:15:30 +
From:David Holland
Message-ID:
| ...and also, for your own and the operator's sanity, skip anything
| else beginning with '.',
That one is probably reasonable (and also possibly some other odd
character, to give an easy way t
> ...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 w
On Fri, Jan 15, 2021 at 05:43:45PM -0800, John Nemeth wrote:
> } We like the idea of being able to include files along with
> } directories. Our current plan is to implement directories first,
> } along with files if time permits us. If we don't have time to
> } implement include-a-file, then w
Date:Fri, 15 Jan 2021 17:43:45 -0800
From:John Nemeth
Message-ID: <202101160143.10g1hjbv018...@server.cornerstoneservice.ca>
| The way to implement including
| directories is to stat the item being included to see if it is a
| directory, and if it is, then branc
On Jan 14, 12:21, James Browning wrote:
}
} >I also don't like the only form of include being include-a-directory;
} >in my estimation, that wires too much policy into the mechanism. I
} >would prefer to see either two include directives, one for directories
} >and one for files, or a single dire
>> That should be true only if you specify a listening address with no
>> command. If it works that way when a command is given on the same
>> line, that's a bug that needs fixing.
> There is no bug, and it is working correctly in the way you
> described. To avoid potential misunderstandings in t
>That should be true only if you specify a listening address with no
>command. If it works that way when a command is given on the same
>line, that's a bug that needs fixing. (I feel moderately authoritative
>on this matter since I'm the person who added the code back in 1996.)
Our apologies. Th
>> inetd.conf already supports per-service overriding of the
>> listen-addr. According to cvsweb, this went in 1996-12-30 (inetd.8
>> rev 1.8, inetd.c rev 1.16).
> Itâ??s true that inetd currently supports specification of the
> listen-addr, however, the way it currently functions is that when
> [
On Thu, Jan 14, 2021 at 12:21:14PM -0800, James Browning wrote:
>
> Our reasoning behind not wanting multiple levels of includedir was to avoid
> overly complex or messy configuration systems, but we see your point. If time
> allows, then we will implement cycle detection.
>
If people want to sh
>That's not the only use for escapes. From a theoretical and aesthetic
>perspective, it would be nice to be able to get arbitrary octet
>sequences into arguments; as outlined, for example, it's not possible
>to get a newline into an argument. (Well, _almost_ arbitrary octet
>sequences. Until and
> The new syntax would look something like:
> on/off key1=value, key2=value1 value2 value3,
> key3=â??this is a valueâ??, key4=value1 value2 â??this is value3â??;
Hm. I think this is about as good a new syntax as we're likely to get.
In particular, it offers a fairly wide variety of extensibilit
Hello again,
We have gone over the community feedback in-depth, and taken into account all of
your suggestions regarding the new backwards-compatible syntax for inetd.conf.
We have drafted a few ideas, and would like to get your thoughts and feedback on
these ideas.
To reiterate the previous thre
17 matches
Mail list logo
