Re: cal(1): Clean up mutually exclusive options
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 that way. >> >> maybe it is more helpful to think of "mutually exclusive" as "causes >> an error", but i am not sure. Probably you are right that my description of "mutually exclusive" as "it errors out" was too narrow and that in some situations, understanding it in a broader sense of "the effect of combining them is unspecified" or even broader, "combining them provides no useful functionality" may be adequate. Still, "mutually exclusive" is not the same concept as "one overrides the other". > I agree with you that programs should not neccessary error out. > > I appreciate that you pointed at ls(1) before, which has so many options > I think we should look there for examples. > > -A List all entries except for `.' and `..'. Always set for the > superuser. > > -a Include directory entries whose names begin with a dot (`.'). > > These two options are not described as mutually exclusive, except, a > mutually exclusive action is described. > > How do -Aa and -aA behave? Try it. Just like -a alone. That is obviously reasonable because both options enlarge the set of names listed, and the set provided by -a is a strict superset of the set provided by -A. > Does POSIX take a position? Not as far as i see. POSIX does explicitly document them as mutually exclusive by having [-a | -A] in the SYNOPSIS, but what happens when both are provided appears to remain unspecified. > If POSIX doesn't take a position, why should we? We probably shouldn't. Since behaviour of -aA is unspecied, our behviour is not only reasonable but also conforming. Strictly speaking, it is undocumented, but easy to guess and certainly not surprising. > Should we break scripts that accidentally use both options? Absolutely not. Even if our page explicitly said "-a and -A are mutually exclusive", that should only be regarded as an indication that the combination *might* error out, not that it actually does - i failed to make that clear in my previous mail. > Argument composition does happen in scripting and interactive use. > > Should we search for places to make POSIX programs exit(1) if people > use them in the newly-defined incorrect way? No. But conversely, we shouldn't attempt to hunt down all cases either where programs currently error out when given mutually exlusive options and make them all override each other. In many cases, it is better to not jump to conclusions when the user didn't make it clear what they wanted. Unsurprisingly, sane behaviour depends on the individual program and options. > If we decide to not cause ls(1) -a and -A to exit, then I think we > should not make other programs exit either. Sounds reasonable. > And then probably follow jmc's lead that "mutually exclusive" either > in text, or in interpreted text, doesn't neccessarily describe an exit > action. That's certainly the current situation. In some pages, it is used for combinations that error out, in some for options that override each other, and when left unqualified, it can mean "the effect of combining is not considered valid syntax and may have an unspecified effect". The latter is often fine (like for ls -aA) and more rarely weird (like for jot -b foo -w bar 3 97). When it is weird, improving it may be worthwhile. Yours, Ingo
Re: cal(1): Clean up mutually exclusive options
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 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 pertinent:
> > >
> > > The order of different options relative to one another should not
> > > matter, unless the options are documented as mutually-exclusive
> > > and such an option is documented to override any incompatible
> > > options preceding it. If an option that has option-arguments is
> > > repeated, the option and option-argument combinations should be
> > > interpreted in the order specified on the command line.
>
> > This is also violated by cal(1)
>
> You seem to misunderstand.
>
> The cal(1) utility does *not* violate this syntax guideline.
> It neither has options where the order on the command line matters
> nor options that take arguments, so this guideline simply makes
> no recommendation whatsoever for cal(1).
>
> > (and maybe others, but this one came
> > up first). Diff below should fix this.
>
> I think the diff is not OK.
>
> It changes established and documented behaviour of a program, and
> you provide no explanation why the new behaviour would be more
> useful than the old one. Also, considering whether this might or
> might not cause compatibility issues would would be required.
>
> Compatibility issues may be unlikely because it merely defines new
> behaviour for something that is now a syntax error. That alone does
> not make the change useful, though.
>
> The change itself seems illogical and confusing to me. If a user
> says "i want days numbered consecutively from Jan 1 *and* week
> numbers displayed in addition", why should the first half of the
> request be ignored? And worse, *silently* ignored? Both halfs of
> the request are unrelated to each other, so both one overriding
> the other and their effect depending on their order would seem
> surprising and hardly useful.
>
> Also, allowing additional syntax makes the user interface more
> complex, which should not be done without a very good reason.
>
> Finally, even *if* we would decide to make the UI more complex and
> allow -jw and -wj (i see no pressing need because -j does not seem
> all that useful in the first place, and needing both at the same
> time would be an even less common task), then the logical behaviour
> would be to simply honour both at the the same time. So your change
> not only makes the UI more complex without a good reason. It also
> blocks syntax space that could, in the future, possibly be assigned
> to more useful functionality.
>
> I admit there are no strong logical reasons why these two options
> have to mutually exclusive. That's seems merely an implementation
> choice to keep the command and documentation simpler. Nothing is
> wrong with having some (not usually needed) functionality unimplemented
> in a program. In this case, this is even properly documented.
>
> To summarize, i oppose the diff as a whole, and i see not parts in
> it that could be salvaged.
>
> Yours,
> Ingo
>
>
> > Index: cal.1
> > ===
> > RCS file: /cvs/src/usr.bin/cal/cal.1,v
> > retrieving revision 1.31
> > diff -u -p -r1.31 cal.1
> > --- cal.1 27 Nov 2016 10:37:22 - 1.31
> > +++ cal.1 15 Aug 2021 21:39:28 -
> > @@ -53,11 +53,8 @@ The options are as follows:
> > .Bl -tag -width Ds
> > .It Fl j
> > Display Julian dates (days one-based, numbered from January 1).
> > -The options
> > -.Fl j
> > -and
> > -.Fl w
> > -are mutually exclusive.
> > +Overrides earlier
> > +.Fl w .
> > .It Fl m
> > Display weeks starting on Monday instead of Sunday.
> > .It Fl w
> > @@ -65,11 +62,8 @@ Display week numbers in the month displa
> > If
> > .Fl m
> > is specified the ISO week format is assumed.
> > -The options
> > -.Fl j
> > -and
> > -.Fl w
> > -are mutually exclusive.
> > +Overrides earlier
> > +.Fl j .
> > .It Fl y
> > Display a calendar for the current year.
> > .El
> > Index: cal.c
> > ===
> > RCS file: /cvs/src/usr.bin/cal/cal.c,v
> > retrieving revision 1.30
> > diff -u -p -r1.30 cal.c
> > --- cal.c 9 Oct 2015 01:37:06 - 1.30
> > +++ cal.c 15 Aug 2021 21:39:28 -
> > @@ -158,12 +158,14 @@ main(int argc, char *argv[])
> > switch(ch) {
> > case 'j':
> > julian = 1;
> > + wflag = 0;
> > break;
> > case 'm':
> > mflag = 1;
> > break;
> > case 'w':
> > wflag = 1;
> > + julian = 0;
>
Re: snmpd: allow sending traps with SNMPv3
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 SNMPv3 messages. > > > > It defaults to the global seclevel, but it can be specified on a per > > > > rule basis. > > > > > > > > Diff requires both previous setting engineid and ober_dup diff. > > > > > > > > Tested with netsnmp's snmptrapd and my WIP diff. > > > > > > > > The other 2 outstanding diffs are for receiving SNMPv3 traps. > > > > > > > > OK? > > > > > > > > martijn@ > > > > > > > Resending now that the engineid diff is in. > > > > > > Still awaiting the commit of ober_dup diff[0]. > > > > > > OK once that one goes in? > > > > > > Also, rereading the diff, splitting the trap receiver in two might be a > > > bit clutch. Once again invoking the manpage gurus. > > > > > > martijn@ > > > > > > [0] https://marc.info/?l=openbsd-tech=162698527126249=2 > > > > > The listen on diff committed this morning broke this patch. > > Updated version > > I think my only concern with this is that the config syntax changes > incompatibly, since you now have to specify 'snmpv2c' for v2c trap > receivers. I can think of a few alternatives, but none of them are > great. What you've done here seems to be the cleanest option both in > terms of what the config looks like and the code for processing it, > so if we're prepared to change the config syntax, I'm happy with it. > To make v3 the default is the logical conclusion of the reason moves away from SNMPv2c in general for our SNMP stack. We've disabled SNMPv2c for listen on in snmpd(8), including trap handle. We've removed default communities (including "trap community"), so enabling snmpv2c on a notify listener will not even make the receiver work without explicitly setting that community. And similar for "trap receiver", without setting either the global "trap community" or the "trap receiver" local community it will not work. It would be easy enough to enable keep snmpv2c the default for trap receiver, but considering the general direction it just seems pointless. In other words, this change is intentional and I assumed that people interested in OKing this diff were aware enough of the recent changes to understand this context of changing defaults. Sorry that that wasn't clear. If noone else objects I'll commit as soon as I get the green light for the libutil bump. Thanks for checking.
Re: sed(1): line addresses and next cycle
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 of > > actually handling a match of '/re/' on the first line without giving us > > another. It would be better to have a clean way of doing the equivalent > > of '0,/re/' than to remove a way to do this. Interestingly (?), the sed > > in plan9port works the same as our native sed. > > As does AT sed on Solaris. Since our sed currently matches the > behavior of the "canonical" sed, I don't see a reason to change it. > > - todd Ack. Like I said, just putting some feelers out. I'll drop the idea.
Re: sed(1): line addresses and next cycle
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 giving us > another. It would be better to have a clean way of doing the equivalent > of '0,/re/' than to remove a way to do this. Interestingly (?), the sed > in plan9port works the same as our native sed. As does AT sed on Solaris. Since our sed currently matches the behavior of the "canonical" sed, I don't see a reason to change it. - todd
Re: cal(1): Clean up mutually exclusive options
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 "causes an > error", but i am not sure. I agree with you that programs should not neccessary error out. I appreciate that you pointed at ls(1) before, which has so many options I think we should look there for examples. -A List all entries except for `.' and `..'. Always set for the superuser. -a Include directory entries whose names begin with a dot (`.'). These two options are not described as mutually exclusive, except, a mutually exclusive action is described. How do -Aa and -aA behave? Try it. Does POSIX take a position? If POSIX doesn't take a position, why should we? Should we break scripts that accidentally use both options? Argument composition does happen in scripting and interactive use. Should we search for places to make POSIX programs exit(1) if people use them in the newly-defined incorrect way? If we decide to not cause ls(1) -a and -A to exit, then I think we should not make other programs exit either. And then probably follow jmc's lead that "mutually exclusive" either in text, or in interpreted text, doesn't neccessarily describe an exit action.
Re: cal(1): Clean up mutually exclusive options
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 incorrect. > > This is what "mutually exclusive" means (without further qualification): > >$ frob -f -u > usage: frob [-f | -u] > > This is what "overrides earlier" means: > >$ frob -f -u > output from successful unfrobnification > >$ frob -u -f > output from successful frobnification > for me, mututally exclusive means simply that you can;t use the options together. it doesn;t specify how a program reacts: - sometimes the program coughs when you use them together (spits out usage) - sometimes it just uses the last match (so silently accepts both; first/last wins) maybe others do not see it that way. i mean, i'm not saying i'm correct, only that this is how i understand the concept. > > 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 sentence structure of "Overrides earlier -f." > > although it's understandable, it reads like there's a word or phrase > > missing. > > Yes, it is an elliptic wording. > > > Overrides earlier instances of -f. Overrides previous -f options. > > Both are still elliptic. > > The intended meaning of the ellipsis is: > > [This option] overrides [any] earlier -f [options]. > yes, i understand about elliptic wording. what i meant was that i felt this form (i.e. elliptic) read badly. > Should we prefer the non-elliptic wording? > well, for me, yes. but i guess other people will prefer the shorter text. > > i just find it clearer when we just say -x and -y are mutually exclusive. > > OK, let's spell this out in full. > > I'm aware of two ways to document "mutually exclusive": > > -f Frobnicate. Mutually exclusive with -u. > -u Unfrobnicate. Mutually exclusive with -f. > > Or: > > -f Frobnicate. > -u Unfrobnicate. > [...] > The options -f and -u are mutually exclusive. > > I have no strong preference either way because if a user specifies both, > they get the usage() message, so the error is likely to be discovered > either way. > well when you have 10 exclusive options (looking at you, ls(1)) then adding the text to every option becomes unwieldy. that's why we did it the second way. but when you just have a couple (much more common) then it can be easier to read in your first example. > > I'm aware of two ways to document "overrides": > > -f Frobnicate. Overrides earlier -u. > -u Unfrobnicate. Overrides earlier -f. > > Or: > > -f Frobnicate. > -u Unfrobnicate. > [...] > The options -f and -u override each other [and the action > is determined by the last one specified]. > > I prefer the the former because the latter is easy to miss (in > addition to being longer), and there is no error message to tell > the user that *something* is going on. > > > Some pages use > > The options -f and -u are mutually exclusive and override each other. > > as a synonym for > > The options -f and -u override each other. > > That may have caused your confusion. Arguably, it might be better > to avoid the somewhat redundant and potentially confusing wording > "are mutually exclusive and override each other". Do you agree? > > Yours, > Ingo 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 "causes an error", but i am not sure. jmc
Re: snmpd: allow sending traps with SNMPv3
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 can be specified on a per > > > rule basis. > > > > > > Diff requires both previous setting engineid and ober_dup diff. > > > > > > Tested with netsnmp's snmptrapd and my WIP diff. > > > > > > The other 2 outstanding diffs are for receiving SNMPv3 traps. > > > > > > OK? > > > > > > martijn@ > > > > > Resending now that the engineid diff is in. > > > > Still awaiting the commit of ober_dup diff[0]. > > > > OK once that one goes in? > > > > Also, rereading the diff, splitting the trap receiver in two might be a > > bit clutch. Once again invoking the manpage gurus. > > > > martijn@ > > > > [0] https://marc.info/?l=openbsd-tech=162698527126249=2 > > > The listen on diff committed this morning broke this patch. > Updated version I think my only concern with this is that the config syntax changes incompatibly, since you now have to specify 'snmpv2c' for v2c trap receivers. I can think of a few alternatives, but none of them are great. What you've done here seems to be the cleanest option both in terms of what the config looks like and the code for processing it, so if we're prepared to change the config syntax, I'm happy with it.
Re: cal(1): Clean up mutually exclusive options
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 sentence structure of "Overrides earlier -f." > although it's understandable, it reads like there's a word or phrase > missing. Overrides earlier instances of -f. Overrides previous -f > options. > > i just find it clearer when we just say -x and -y are mutually exclusive. > > jmc Not a fan of telegram style so. https://en.wikipedia.org/wiki/Telegram_style https://en.wikipedia.org/wiki/Headline#Headlinese https://en.wikipedia.org/wiki/Ellipsis_(linguistics) I take no position on the matter before this cal(1) cleanup court, but I contend that clipped sentences can be clearly cromulent. Cleverly copacetic, even. 'Cool. Ian
Re: cal(1): Clean up mutually exclusive options
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 qualification): $ frob -f -u usage: frob [-f | -u] This is what "overrides earlier" means: $ frob -f -u output from successful unfrobnification $ frob -u -f output from successful frobnification > 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 sentence structure of "Overrides earlier -f." > although it's understandable, it reads like there's a word or phrase > missing. Yes, it is an elliptic wording. > Overrides earlier instances of -f. Overrides previous -f options. Both are still elliptic. The intended meaning of the ellipsis is: [This option] overrides [any] earlier -f [options]. Should we prefer the non-elliptic wording? > i just find it clearer when we just say -x and -y are mutually exclusive. OK, let's spell this out in full. I'm aware of two ways to document "mutually exclusive": -f Frobnicate. Mutually exclusive with -u. -u Unfrobnicate. Mutually exclusive with -f. Or: -f Frobnicate. -u Unfrobnicate. [...] The options -f and -u are mutually exclusive. I have no strong preference either way because if a user specifies both, they get the usage() message, so the error is likely to be discovered either way. I'm aware of two ways to document "overrides": -f Frobnicate. Overrides earlier -u. -u Unfrobnicate. Overrides earlier -f. Or: -f Frobnicate. -u Unfrobnicate. [...] The options -f and -u override each other [and the action is determined by the last one specified]. I prefer the the former because the latter is easy to miss (in addition to being longer), and there is no error message to tell the user that *something* is going on. Some pages use The options -f and -u are mutually exclusive and override each other. as a synonym for The options -f and -u override each other. That may have caused your confusion. Arguably, it might be better to avoid the somewhat redundant and potentially confusing wording "are mutually exclusive and override each other". Do you agree? Yours, Ingo
Re: cal(1): Clean up mutually exclusive options
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 really. I'm not a native speaker, but i would understand "mutually exclusive" to mean "program probably terminates with an error", whereas "overrides earlier" is "program uses later option and continues to do whatever its suposed to".
Re: cal(1): Clean up mutually exclusive options
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 *gratuitiously* violating POSIX utility syntax guidelines though, for two reasons: 1. They make sense independently of the fact that they are in POSIX. 2. Following this (small) set of (relatively unintrusive) guidelines helps with designing a harmonious user experience all across the system. On the one hand, it helps avoiding surprises. On the other hand, it saves the user from having to learn completely new ways of constructing syntax for every new command. But this is unrelated to martijn@'s cal(1) diff. POSIX provides no arguments for or against that diff as far as i'm aware. Yours, Ingo
Re: cal(1): Clean up mutually exclusive options
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 overrides another and order does not > matter - for example, "lock -n -t -1" is the same as just "lock -n", > even though -t comes after -n. > > But if options override *each other*, that means the last one wins > unless otherwise stated. > > A utility can also be designed such that some options override each > other and the first one wins, but usually, i wouldn't consider that > ideal UI design in a command line utility. In configuration files, > on the other hand, both "first one wins" and "last one wins" exist. > For that reason, nothing much seems wrong with being explicit that > the last one wins, where that is the case. > > > and then not document this fact every time. or at least document > > exceptions only? > > > > ...and continue to document where options are mutually exclusive? > > > > also the text "overrides earlier" is unclear. > > In which sense do you consider > > -f Frobnicate. Overrides earlier -u. > -l [...] > -n [...] > -u Unfrobnicate. Overrides earlier -f. > > unclear? Options exclusively appear on the command line, so i don't > see how "earlier" or "later" could possibly refer to anything else > than the position on the command line. > > Note that this seems only loosely related to martijn@'s diff, which > i think is undesirable for other, stronger reasons. > > Yours, > Ingo 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 sentence structure of "Overrides earlier -f." although it's understandable, it reads like there's a word or phrase missing. Overrides earlier instances of -f. Overrides previous -f options. i just find it clearer when we just say -x and -y are mutually exclusive. jmc
Re: cal(1): Clean up mutually exclusive options
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 same as just "lock -n", even though -t comes after -n. But if options override *each other*, that means the last one wins unless otherwise stated. A utility can also be designed such that some options override each other and the first one wins, but usually, i wouldn't consider that ideal UI design in a command line utility. In configuration files, on the other hand, both "first one wins" and "last one wins" exist. For that reason, nothing much seems wrong with being explicit that the last one wins, where that is the case. > and then not document this fact every time. or at least document > exceptions only? > > ...and continue to document where options are mutually exclusive? > > also the text "overrides earlier" is unclear. In which sense do you consider -f Frobnicate. Overrides earlier -u. -l [...] -n [...] -u Unfrobnicate. Overrides earlier -f. unclear? Options exclusively appear on the command line, so i don't see how "earlier" or "later" could possibly refer to anything else than the position on the command line. Note that this seems only loosely related to martijn@'s diff, which i think is undesirable for other, stronger reasons. Yours, Ingo
Re: cal(1): Clean up mutually exclusive options
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 pertinent:
>>
>> The order of different options relative to one another should not
>> matter, unless the options are documented as mutually-exclusive
>> and such an option is documented to override any incompatible
>> options preceding it. If an option that has option-arguments is
>> repeated, the option and option-argument combinations should be
>> interpreted in the order specified on the command line.
> This is also violated by cal(1)
You seem to misunderstand.
The cal(1) utility does *not* violate this syntax guideline.
It neither has options where the order on the command line matters
nor options that take arguments, so this guideline simply makes
no recommendation whatsoever for cal(1).
> (and maybe others, but this one came
> up first). Diff below should fix this.
I think the diff is not OK.
It changes established and documented behaviour of a program, and
you provide no explanation why the new behaviour would be more
useful than the old one. Also, considering whether this might or
might not cause compatibility issues would would be required.
Compatibility issues may be unlikely because it merely defines new
behaviour for something that is now a syntax error. That alone does
not make the change useful, though.
The change itself seems illogical and confusing to me. If a user
says "i want days numbered consecutively from Jan 1 *and* week
numbers displayed in addition", why should the first half of the
request be ignored? And worse, *silently* ignored? Both halfs of
the request are unrelated to each other, so both one overriding
the other and their effect depending on their order would seem
surprising and hardly useful.
Also, allowing additional syntax makes the user interface more
complex, which should not be done without a very good reason.
Finally, even *if* we would decide to make the UI more complex and
allow -jw and -wj (i see no pressing need because -j does not seem
all that useful in the first place, and needing both at the same
time would be an even less common task), then the logical behaviour
would be to simply honour both at the the same time. So your change
not only makes the UI more complex without a good reason. It also
blocks syntax space that could, in the future, possibly be assigned
to more useful functionality.
I admit there are no strong logical reasons why these two options
have to mutually exclusive. That's seems merely an implementation
choice to keep the command and documentation simpler. Nothing is
wrong with having some (not usually needed) functionality unimplemented
in a program. In this case, this is even properly documented.
To summarize, i oppose the diff as a whole, and i see not parts in
it that could be salvaged.
Yours,
Ingo
> Index: cal.1
> ===
> RCS file: /cvs/src/usr.bin/cal/cal.1,v
> retrieving revision 1.31
> diff -u -p -r1.31 cal.1
> --- cal.1 27 Nov 2016 10:37:22 - 1.31
> +++ cal.1 15 Aug 2021 21:39:28 -
> @@ -53,11 +53,8 @@ The options are as follows:
> .Bl -tag -width Ds
> .It Fl j
> Display Julian dates (days one-based, numbered from January 1).
> -The options
> -.Fl j
> -and
> -.Fl w
> -are mutually exclusive.
> +Overrides earlier
> +.Fl w .
> .It Fl m
> Display weeks starting on Monday instead of Sunday.
> .It Fl w
> @@ -65,11 +62,8 @@ Display week numbers in the month displa
> If
> .Fl m
> is specified the ISO week format is assumed.
> -The options
> -.Fl j
> -and
> -.Fl w
> -are mutually exclusive.
> +Overrides earlier
> +.Fl j .
> .It Fl y
> Display a calendar for the current year.
> .El
> Index: cal.c
> ===
> RCS file: /cvs/src/usr.bin/cal/cal.c,v
> retrieving revision 1.30
> diff -u -p -r1.30 cal.c
> --- cal.c 9 Oct 2015 01:37:06 - 1.30
> +++ cal.c 15 Aug 2021 21:39:28 -
> @@ -158,12 +158,14 @@ main(int argc, char *argv[])
> switch(ch) {
> case 'j':
> julian = 1;
> + wflag = 0;
> break;
> case 'm':
> mflag = 1;
> break;
> case 'w':
> wflag = 1;
> + julian = 0;
> break;
> case 'y':
> yflag = 1;
> @@ -174,9 +176,6 @@ main(int argc, char *argv[])
> }
> argc -= optind;
> argv += optind;
> -
> - if (julian && wflag)
> - usage();
>
> day_headings = DAY_HEADINGS_S;
> sep1752 = sep1752s;
