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 <j...@kerhand.co.uk> wrote:
> On 15 August 2021 22:40:49 BST, Martijn van Duren
> <openbsd+t...@list.imperialat.at> 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 -0000 1.31
> >+++ cal.1 15 Aug 2021 21:39:28 -0000
> >@@ -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 -0000 1.30
> >+++ cal.c 15 Aug 2021 21:39:28 -0000
> >@@ -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
>
