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 <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
> >
