Hi Theo,
Theo de Raadt wrote on Mon, Aug 16, 2021 at 08:15:03AM -0600:
> Jason McIntyre wrote:
>> well, in those cases i think the authors shared the viewpoint that
>> mutually exclusive means you can;t mix them but in this case it is
>> essentially not an error to do so, and so documented it th
Ok, I'll drop the diff. I misunderstood our previous conversation.
Sorry for the stir it caused.
On Mon, 2021-08-16 at 12:31 +0200, Ingo Schwarze wrote:
> Hi Martijn,
>
> Martijn van Duren wrote on Sun, Aug 15, 2021 at 11:40:49PM +0200:
> > To quote schwarze in the jot mutually exclusive thread:
On Mon, 2021-08-16 at 22:45 +1000, Jonathan Matthew wrote:
> On Tue, Aug 10, 2021 at 12:58:05PM +0200, Martijn van Duren wrote:
> > On Mon, 2021-08-09 at 21:44 +0200, Martijn van Duren wrote:
> > > On Tue, 2021-07-27 at 21:28 +0200, Martijn van Duren wrote:
> > > > This diff allows sending traps in
On Mon, 2021-08-16 at 08:25 -0600, Todd C. Miller wrote:
> On Sun, 15 Aug 2021 23:56:54 +0200, Andreas Kusalananda
> =?utf-8?B?S8OkaMOkcmk=?
> = wrote:
>
> > But note that this comes out of a discussion on how to do '0,/re/'
> > addressing with OpenBSD sed. Your changes appears to remove one way
On Sun, 15 Aug 2021 23:56:54 +0200, Andreas Kusalananda =?utf-8?B?S8OkaMOkcmk=?
= wrote:
> But note that this comes out of a discussion on how to do '0,/re/'
> addressing with OpenBSD sed. Your changes appears to remove one way of
> actually handling a match of '/re/' on the first line without gi
Jason McIntyre wrote:
> well, in those cases i think the authors shared the viewpoint that
> mutually exclusive means you can;t mix them but in this case it is
> essentially not an error to do so, and so documented it that way.
>
> maybe it is more helpful to think of "mutually exclusive" as "ca
On Mon, Aug 16, 2021 at 01:45:30PM +0200, Ingo Schwarze wrote:
> Hi Jason,
>
> Jason McIntyre wrote on Mon, Aug 16, 2021 at 12:02:13PM +0100:
>
> > when i wrote my mail, i failed to understand that "overrides earlier"
> > was really just another way of saying "mutually exclusive".
>
> That is in
On Tue, Aug 10, 2021 at 12:58:05PM +0200, Martijn van Duren wrote:
> On Mon, 2021-08-09 at 21:44 +0200, Martijn van Duren wrote:
> > On Tue, 2021-07-27 at 21:28 +0200, Martijn van Duren wrote:
> > > This diff allows sending traps in SNMPv3 messages.
> > > It defaults to the global seclevel, but it
On 16/08/2021, Jason McIntyre wrote:
> hi.
>
> when i wrote my mail, i failed to understand that "overrides earlier"
> was really just another way of saying "mutually exclusive". i don;t find
> it as clear, and i don;t hugely like it, but i guess it's just my
> preference.
>
> i also dislike the s
Hi Jason,
Jason McIntyre wrote on Mon, Aug 16, 2021 at 12:02:13PM +0100:
> when i wrote my mail, i failed to understand that "overrides earlier"
> was really just another way of saying "mutually exclusive".
That is incorrect.
This is what "mutually exclusive" means (without further qualificatio
Jason McIntyre(j...@kerhand.co.uk) on 2021.08.16 12:02:13 +0100:
> when i wrote my mail, i failed to understand that "overrides earlier"
> was really just another way of saying "mutually exclusive". i don;t find
> it as clear, and i don;t hugely like it, but i guess it's just my
> preference.
Not
Hi Theo,
Theo de Raadt wrote on Sun, Aug 15, 2021 at 05:42:13PM -0600:
> Is it really reasonable that we should strictly follow a non-applicable
> standard in such rarely used non-standard utilities,
Not strictly, no. Usefulness needs to be considered in individual
cases.
There is value in not
On Mon, Aug 16, 2021 at 12:53:38PM +0200, Ingo Schwarze wrote:
> Hi Jason,
>
> Jason McIntyre wrote on Sun, Aug 15, 2021 at 11:30:05PM +0100:
>
> > can't we take a stance that where options override each other,
> > the last one wins?
>
> Yes, that is possible.
>
> Cases exist where one option o
Hi Jason,
Jason McIntyre wrote on Sun, Aug 15, 2021 at 11:30:05PM +0100:
> can't we take a stance that where options override each other,
> the last one wins?
Yes, that is possible.
Cases exist where one option overrides another and order does not
matter - for example, "lock -n -t -1" is the sa
Hi Martijn,
Martijn van Duren wrote on Sun, Aug 15, 2021 at 11:40:49PM +0200:
> To quote schwarze in the jot mutually exclusive thread:
> On Fri, 2021-08-13 at 11:48 +0200, Ingo Schwarze wrote:
>> In this case, even though this is not a POSIX command, POSIX utility
>> convention 12.2.11 is pertin
15 matches
Mail list logo
