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: 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: 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;
Re: cal(1): Clean up mutually exclusive options
On Sun, Aug 15, 2021 at 05:42:13PM -0600, Theo de Raadt wrote: > This conversation is strange, because we had a very similar argument > recently about some other command (I forgot which one), about what > policy should occur for repeated commands. > > I think once we step outside a narrowly defined POSIX option argument > scheme, we need to understand we are outside POSIX. Meanwhile, there > is this "sed and line 0" conversation flowing through my mailbox, where > a strictly defined POSIX command's GNU extensions causes people trouble. > > Is it really reasonable that we should strictly follow a non-applicable > standard in such rarely used non-standard utilities, when > strictly-standardized utilities so often have non-standard extensions > which acutely poison the user expectations in more harmful ways (meaning, > incorrect results IN SCRIPTS). > > We can't push back against established facts in sed because it would break > people's scripts somewhere, why do we need to push back against established > facts for people who might use cal in this weird way in a script? > > Beyond the theory of "lacking guidance, let's impose a POSIX rule after > the fact", has there been any attempt to JUDGE if this will affect anyone > in scripts? > not by me, and that's a good point. i wouldn;t even know how to examine such a thing. from my point of view i supposed that last option winning was the general way of things and it would be enough to have that presumed and not documented, but obviously we would document commands where this does not occur. so for cal(1), i figured it unneccessary to document this fact. i guess if it is a change in behaviour (i'm unsure whether that is the case) then i guess we might have to document it. jmc > Jason McIntyre wrote: > > > On 15 August 2021 22:40:49 BST, Martijn van Duren > > wrote: > > >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) (and maybe others, but this one came > > >up first). Diff below should fix this. > > > > > >OK? > > > > > >martijn@ > > > > > >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; > > > > > > > > > > hi. > > > > i don't like this approach, because i think the changes are confusing. > > > > can't we take a stance that where options override each other, the last one > > wins? and then not document this fact every time. or at least document > >
Re: cal(1): Clean up mutually exclusive options
This conversation is strange, because we had a very similar argument recently about some other command (I forgot which one), about what policy should occur for repeated commands. I think once we step outside a narrowly defined POSIX option argument scheme, we need to understand we are outside POSIX. Meanwhile, there is this "sed and line 0" conversation flowing through my mailbox, where a strictly defined POSIX command's GNU extensions causes people trouble. Is it really reasonable that we should strictly follow a non-applicable standard in such rarely used non-standard utilities, when strictly-standardized utilities so often have non-standard extensions which acutely poison the user expectations in more harmful ways (meaning, incorrect results IN SCRIPTS). We can't push back against established facts in sed because it would break people's scripts somewhere, why do we need to push back against established facts for people who might use cal in this weird way in a script? Beyond the theory of "lacking guidance, let's impose a POSIX rule after the fact", has there been any attempt to JUDGE if this will affect anyone in scripts? Jason McIntyre wrote: > On 15 August 2021 22:40:49 BST, Martijn van Duren > wrote: > >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) (and maybe others, but this one came > >up first). Diff below should fix this. > > > >OK? > > > >martijn@ > > > >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.127 Nov 2016 10:37:22 - 1.31 > >+++ cal.115 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.c9 Oct 2015 01:37:06 - 1.30 > >+++ cal.c15 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; > > > > > > hi. > > i don't like this approach, because i think the changes are confusing. > > can't we take a stance that where options override each other, the last one > wins? 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. > > jmc >
Re: cal(1): Clean up mutually exclusive options
On 15 August 2021 22:40:49 BST, Martijn van Duren wrote: >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) (and maybe others, but this one came >up first). Diff below should fix this. > >OK? > >martijn@ > >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; > > hi. i don't like this approach, because i think the changes are confusing. can't we take a stance that where options override each other, the last one wins? 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. jmc
cal(1): Clean up mutually exclusive options
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) (and maybe others, but this one came up first). Diff below should fix this. OK? martijn@ 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;