[PATCH 1/2] cal: honor num_months when only a year argument

[PATCH 1/2] cal: honor num_months when only a year argument

[J William Piggott]

I don't know if this was an oversight or an overzealous
interpretation of POSIX. Just in case, I'll address the
POSIX possibility. POSIX description for cal(1) says:

  If only the year operand is given, cal shall produce a
  calendar for all twelve months in the given calendar year.

It also says that cal(1) has no options, so in that context
if an option is given then it should be expected to override
POSIX behavior.

Before patched all of these command displayed a full year:
cal -1 2020
cal -3 2020
cal -n6 2020

Patched the number of months options are honored.

This patch also fixes the -1 option which was a no-op.

Signed-off-by: J William Piggott <elseifthen@gmx.com>
---
 misc-utils/cal.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/misc-utils/cal.c b/misc-utils/cal.c
index 5a6364a27..8a715d94c 100644
--- a/misc-utils/cal.c
+++ b/misc-utils/cal.c
@@ -267,7 +267,6 @@ int main(int argc, char **argv)
 	static struct cal_control ctl = {
 		.reform_year = DEFAULT_REFORM_YEAR,
 		.weekstart = SUNDAY,
-		.num_months = 1,		/* default is "cal -1" */
 		.span_months = 0,
 		.colormode = UL_COLORMODE_UNDEF,
 		.weektype = WEEK_NUM_DISABLED,
@@ -363,7 +362,7 @@ int main(int argc, char **argv)
 
 		switch(ch) {
 		case '1':
-			/* default */
+			ctl.num_months = 1;
 			break;
 		case '3':
 			ctl.num_months = 3;
@@ -536,7 +535,8 @@ int main(int argc, char **argv)
 
 	if (yflag || Yflag) {
 		ctl.gutter_width = 3;
-		ctl.num_months = MONTHS_IN_YEAR;
+		if (!ctl.num_months)
+			ctl.num_months = MONTHS_IN_YEAR;
 		if (yflag) {
 			ctl.req.start_month = 1;	/* start from Jan */
 			ctl.header_year = 1;		/* print year number */
@@ -549,6 +549,9 @@ int main(int argc, char **argv)
 	else if (!ctl.months_in_row)
 		ctl.months_in_row = 1;
 
+	if (!ctl.num_months)
+		ctl.num_months = 1;		/* display at least one month */
+
 	if (yflag || Yflag)
 		yearly(&ctl);
 	else

[PATCH 2/2] cal: do not set months_in_row with -3 option

[J William Piggott]

Having the -3 option set months_in_row causes ordinal days
to wrap; it overrides the automatic handling of months_in_row
that falls back to 2 month columns for ordinal days.

Before:
cal -3j 2020
                           2020

            July                         August                      September
Sun Mon Tue Wed Thu Fri Sat   Sun Mon Tue Wed Thu Fri Sat   Sun Mon Tue Wed Thu Fri Sat
    182 183 184 185 186 187                   213 214 215   244 245 246 247 248 249 250
188 189 190 191 192 193 194   216 217 218 219 220 221 222   251 252 253 254 255 256 257
195 196 197 198 199 200 201   223 224 225 226 227 228 229   258 259 260 261 262 263 264
202 203 204 205 206 207 208   230 231 232 233 234 235 236   265 266 267 268 269 270 271
209 210 211 212               237 238 239 240 241 242 243   272 273

Patched:
cal -3j 2020
                           2020

          December                      January
Sun Mon Tue Wed Thu Fri Sat   Sun Mon Tue Wed Thu Fri Sat
335 336 337 338 339 340 341                 1   2   3   4
342 343 344 345 346 347 348     5   6   7   8   9  10  11
349 350 351 352 353 354 355    12  13  14  15  16  17  18
356 357 358 359 360 361 362    19  20  21  22  23  24  25
363 364 365                    26  27  28  29  30  31

          February
Sun Mon Tue Wed Thu Fri Sat
                         32
 33  34  35  36  37  38  39
 40  41  42  43  44  45  46
 47  48  49  50  51  52  53
 54  55  56  57  58  59  60

Signed-off-by: J William Piggott <elseifthen@gmx.com>
---
 misc-utils/cal.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/misc-utils/cal.c b/misc-utils/cal.c
index 8a715d94c..a38ca3024 100644
--- a/misc-utils/cal.c
+++ b/misc-utils/cal.c
@@ -367,7 +367,6 @@ int main(int argc, char **argv)
 		case '3':
 			ctl.num_months = 3;
 			ctl.span_months = 1;
-			ctl.months_in_row = 3;
 			break;
 		case 's':
 			ctl.weekstart = SUNDAY;		/* default */

Re: [PATCH 2/2] cal: do not set months_in_row with -3 option

[Karel Zak]

On Mon, Jan 22, 2018 at 03:07:15PM -0500, J William Piggott wrote:
> 
> Having the -3 option set months_in_row causes ordinal days
> to wrap; it overrides the automatic handling of months_in_row
> that falls back to 2 month columns for ordinal days.
> 
> Before:
> cal -3j 2020
>                            2020
> 
>             July                         August                      September
> Sun Mon Tue Wed Thu Fri Sat   Sun Mon Tue Wed Thu Fri Sat   Sun Mon Tue Wed Thu Fri Sat
>     182 183 184 185 186 187                   213 214 215   244 245 246 247 248 249 250
> 188 189 190 191 192 193 194   216 217 218 219 220 221 222   251 252 253 254 255 256 257
> 195 196 197 198 199 200 201   223 224 225 226 227 228 229   258 259 260 261 262 263 264
> 202 203 204 205 206 207 208   230 231 232 233 234 235 236   265 266 267 268 269 270 271
> 209 210 211 212               237 238 239 240 241 242 243   272 273
> 
> Patched:
> cal -3j 2020
>                            2020
> 
>           December                      January
> Sun Mon Tue Wed Thu Fri Sat   Sun Mon Tue Wed Thu Fri Sat
> 335 336 337 338 339 340 341                 1   2   3   4
> 342 343 344 345 346 347 348     5   6   7   8   9  10  11
> 349 350 351 352 353 354 355    12  13  14  15  16  17  18
> 356 357 358 359 360 361 362    19  20  21  22  23  24  25
> 363 364 365                    26  27  28  29  30  31
> 
>           February
> Sun Mon Tue Wed Thu Fri Sat
>                          32
>  33  34  35  36  37  38  39
>  40  41  42  43  44  45  46
>  47  48  49  50  51  52  53
>  54  55  56  57  58  59  60

Merged, but the patch breaks regression tests. It would be nice to fix
it ASAP.

It would be nice to be smart and use include/ttyutils.h:get_terminal_width()
if stdout is terminal. For non-terminal output we can use always 3 columns.

See patch below. It's not perfect, because we have extra blank space
behind last column, but good enough to show the idea. For really small
terms it uses one month, etc.

    Karel


diff --git a/misc-utils/cal.c b/misc-utils/cal.c
index 562ae2afb..688377189 100644
--- a/misc-utils/cal.c
+++ b/misc-utils/cal.c
@@ -75,6 +75,7 @@
 #include "strutils.h"
 #include "optutils.h"
 #include "timeutils.h"
+#include "ttyutils.h"
 
 static int has_term = 0;
 static const char *Senter = "", *Sexit = "";	/* enter and exit standout mode */
@@ -542,10 +543,19 @@ int main(int argc, char **argv)
 		}
 	}
 
-	if (ctl.num_months > 1 && ctl.months_in_row == 0)
-		ctl.months_in_row = ctl.julian ? MONTHS_IN_YEAR_ROW - 1 :
-						 MONTHS_IN_YEAR_ROW;
-	else if (!ctl.months_in_row)
+#define DOY_MONTH_WIDTH	28	/* -j */
+#define DOM_MONTH_WIDTH 23
+
+	if (ctl.num_months > 1 && ctl.months_in_row == 0) {
+		if (isatty(STDOUT_FILENO)) {
+			int w = get_terminal_width(STDOUT_FILENO);
+			int mw = ctl.julian ? DOY_MONTH_WIDTH : DOM_MONTH_WIDTH;
+
+			ctl.months_in_row = w  / mw;
+		} else
+			ctl.months_in_row = MONTHS_IN_YEAR_ROW;
+
+	} else if (!ctl.months_in_row)
 		ctl.months_in_row = 1;
 
 	if (!ctl.num_months)

Re: [PATCH 1/2] cal: honor num_months when only a year argument

[Karel Zak]

On Mon, Jan 22, 2018 at 03:05:08PM -0500, J William Piggott wrote:
> It also says that cal(1) has no options, so in that context
> if an option is given then it should be expected to override
> POSIX behavior.
> 
> Before patched all of these command displayed a full year:
> cal -1 2020
> cal -3 2020
> cal -n6 2020

It enables *year header*, and for one month is looks strange,
especially if you don't asked for it.

$ ./cal -1 2018
                               2018                               

       January      
Su Mo Tu We Th Fr Sa
    1  2  3  4  5  6  
 7  8  9 10 11 12 13  
14 15 16 17 18 19 20  
21 22 23 24 25 26 27  
28 29 30 31           


The problem is that <year> command line argument enables yflag, but in
this case it does not make sense. I guess solution is something like:

diff --git a/misc-utils/cal.c b/misc-utils/cal.c
index 562ae2afb..82f3e4558 100644
--- a/misc-utils/cal.c
+++ b/misc-utils/cal.c
@@ -484,7 +484,8 @@ int main(int argc, char **argv)
                }
                if (!ctl.req.month && !ctl.req.week) {
                        ctl.req.month = local_time->tm_mon + 1;
-                       yflag = 1;
+                       if (!ctl.num_months)
+                               yflag = 1;
                }
                break;
        case 0:


It means that header for "-1|-3|-n <year>" is the same as without
<year>.

Fixed version:

$ ./cal -1 2020
    January 2020    
Su Mo Tu We Th Fr Sa
          1  2  3  4 
 5  6  7  8  9 10 11 
12 13 14 15 16 17 18 
19 20 21 22 23 24 25 
26 27 28 29 30 31                       

$ ./cal -3 2020
    December 2019         January 2020          February 2020   
Su Mo Tu We Th Fr Sa  Su Mo Tu We Th Fr Sa  Su Mo Tu We Th Fr Sa
 1  2  3  4  5  6  7            1  2  3  4                     1 
 8  9 10 11 12 13 14   5  6  7  8  9 10 11   2  3  4  5  6  7  8 
15 16 17 18 19 20 21  12 13 14 15 16 17 18   9 10 11 12 13 14 15 
22 23 24 25 26 27 28  19 20 21 22 23 24 25  16 17 18 19 20 21 22 
29 30 31              26 27 28 29 30 31     23 24 25 26 27 28 29 
                                          
You can force year header by explicit -y on command line:

./cal -3y 2020
                               2020

      December                January               February
Su Mo Tu We Th Fr Sa   Su Mo Tu We Th Fr Sa   Su Mo Tu We Th Fr Sa
 1  2  3  4  5  6  7             1  2  3  4                      1
 8  9 10 11 12 13 14    5  6  7  8  9 10 11    2  3  4  5  6  7  8
15 16 17 18 19 20 21   12 13 14 15 16 17 18    9 10 11 12 13 14 15
22 23 24 25 26 27 28   19 20 21 22 23 24 25   16 17 18 19 20 21 22
29 30 31               26 27 28 29 30 31      23 24 25 26 27 28 29


IMHO it's more consistent behavior. 

We need to add a note to the man page that -y forces cal(1) to use 
year header in all contexts.

Comments?

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: [PATCH 1/2] cal: honor num_months when only a year argument

[J William Piggott]

On 01/24/2018 07:54 AM, Karel Zak wrote:
> On Mon, Jan 22, 2018 at 03:05:08PM -0500, J William Piggott wrote:

8< ...

> We need to add a note to the man page that -y forces cal(1) to use 
> year header in all contexts.
> 
> Comments?

Well, this is a case where I damned if I do and damned if I don't.

In my queue of patches I address this problem. If I submit them all at
once it's a problem for reviewing. If I piecemeal the changes then they
don't make sense. Sometimes I wish that I could present the final result
before submitting any patches.

The year header is currently broken in other contexts as well; it is
better to keep it in the month header as it is for all other output.
Then I repurpose the top header to display the calendar system:
Gregorian, Julian, Mixed. I think this is needed now that we have
multiple options that control which calendar system is being displayed.
You want to add more reform dates in the future which will make showing
which calendar system is displayed all the more relevant.

I'll post my next set and hopefully you will see where I'm going.

Note: the next set is intended to apply on top of these two patches.

> 
>     Karel
> 

Re: [PATCH 1/2] cal: honor num_months when only a year argument

[Ruediger Meier]

On Monday 22 January 2018, J William Piggott wrote:
> I don't know if this was an oversight or an overzealous
> interpretation of POSIX. Just in case, I'll address the
> POSIX possibility. POSIX description for cal(1) says:
>
>   If only the year operand is given, cal shall produce a
>   calendar for all twelve months in the given calendar year.
>
> It also says that cal(1) has no options, so in that context
> if an option is given then it should be expected to override
> POSIX behavior.

We still don't need to fight against POSIX.

"cal -1" behaves like POSIX cal without options.
"cal -3" behaves like POSIX except that it prints 3 months whereever  
POSIX would print only 1.

> Before patched all of these command displayed a full year:
> cal -1 2020
> cal -3 2020
> cal -n6 2020

Seriously, I find the new behavior quiet useless and unwanted. In past 
it seemed to work fine to have such alias in ~./profile

  alias cal="cal -3"


But now "cal -3 2019" always shows Dec, Jan, Feb. Can't believe that any 
user finds this useful. At least it should output of the "current" 
months of the given year. But I wouldn't change this at all. It's just 
an annoying incompatible change without any benefit.


cu,
Rudi


> Patched the number of months options are honored.
>
> This patch also fixes the -1 option which was a no-op.
>
> Signed-off-by: J William Piggott <elseifthen@gmx.com>
> ---
>  misc-utils/cal.c | 9 ++++++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/misc-utils/cal.c b/misc-utils/cal.c
> index 5a6364a27..8a715d94c 100644
> --- a/misc-utils/cal.c
> +++ b/misc-utils/cal.c
> @@ -267,7 +267,6 @@ int main(int argc, char **argv)
>  	static struct cal_control ctl = {
>  		.reform_year = DEFAULT_REFORM_YEAR,
>  		.weekstart = SUNDAY,
> -		.num_months = 1,		/* default is "cal -1" */
>  		.span_months = 0,
>  		.colormode = UL_COLORMODE_UNDEF,
>  		.weektype = WEEK_NUM_DISABLED,
> @@ -363,7 +362,7 @@ int main(int argc, char **argv)
>
>  		switch(ch) {
>  		case '1':
> -			/* default */
> +			ctl.num_months = 1;
>  			break;
>  		case '3':
>  			ctl.num_months = 3;
> @@ -536,7 +535,8 @@ int main(int argc, char **argv)
>
>  	if (yflag || Yflag) {
>  		ctl.gutter_width = 3;
> -		ctl.num_months = MONTHS_IN_YEAR;
> +		if (!ctl.num_months)
> +			ctl.num_months = MONTHS_IN_YEAR;
>  		if (yflag) {
>  			ctl.req.start_month = 1;	/* start from Jan */
>  			ctl.header_year = 1;		/* print year number */
> @@ -549,6 +549,9 @@ int main(int argc, char **argv)
>  	else if (!ctl.months_in_row)
>  		ctl.months_in_row = 1;
>
> +	if (!ctl.num_months)
> +		ctl.num_months = 1;		/* display at least one month */
> +
>  	if (yflag || Yflag)
>  		yearly(&ctl);
>  	else
> --
> To unsubscribe from this list: send the line "unsubscribe util-linux"
> in the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] cal: honor num_months when only a year argument

[Ruediger Meier]

On Wednesday 24 January 2018, Ruediger Meier wrote:
> On Monday 22 January 2018, J William Piggott wrote:
> > I don't know if this was an oversight or an overzealous
> > interpretation of POSIX. Just in case, I'll address the
> > POSIX possibility. POSIX description for cal(1) says:
> >
> >   If only the year operand is given, cal shall produce a
> >   calendar for all twelve months in the given calendar year.
> >
> > It also says that cal(1) has no options, so in that context
> > if an option is given then it should be expected to override
> > POSIX behavior.
>
> We still don't need to fight against POSIX.
>
> "cal -1" behaves like POSIX cal without options.
> "cal -3" behaves like POSIX except that it prints 3 months whereever
> POSIX would print only 1.

Hm, actually I see cal -3 is broken since
   v2.27-45-gccf3dd50c  "cal: Add --span option"


$ cal -3 2010

does the same like 

$ cal --span -3 2010


> > Before patched all of these command displayed a full year:
> > cal -1 2020
> > cal -3 2020
> > cal -n6 2020
>
> Seriously, I find the new behavior quiet useless and unwanted. In
> past it seemed to work fine to have such alias in ~./profile
>
>   alias cal="cal -3"
>
>
> But now "cal -3 2019" always shows Dec, Jan, Feb. Can't believe that
> any user finds this useful. At least it should output of the
> "current" months of the given year. But I wouldn't change this at
> all. It's just an annoying incompatible change without any benefit.
>
>
> cu,
> Rudi
>
> > Patched the number of months options are honored.
> >
> > This patch also fixes the -1 option which was a no-op.
> >
> > Signed-off-by: J William Piggott <elseifthen@gmx.com>
> > ---
> >  misc-utils/cal.c | 9 ++++++---
> >  1 file changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/misc-utils/cal.c b/misc-utils/cal.c
> > index 5a6364a27..8a715d94c 100644
> > --- a/misc-utils/cal.c
> > +++ b/misc-utils/cal.c
> > @@ -267,7 +267,6 @@ int main(int argc, char **argv)
> >  	static struct cal_control ctl = {
> >  		.reform_year = DEFAULT_REFORM_YEAR,
> >  		.weekstart = SUNDAY,
> > -		.num_months = 1,		/* default is "cal -1" */
> >  		.span_months = 0,
> >  		.colormode = UL_COLORMODE_UNDEF,
> >  		.weektype = WEEK_NUM_DISABLED,
> > @@ -363,7 +362,7 @@ int main(int argc, char **argv)
> >
> >  		switch(ch) {
> >  		case '1':
> > -			/* default */
> > +			ctl.num_months = 1;
> >  			break;
> >  		case '3':
> >  			ctl.num_months = 3;
> > @@ -536,7 +535,8 @@ int main(int argc, char **argv)
> >
> >  	if (yflag || Yflag) {
> >  		ctl.gutter_width = 3;
> > -		ctl.num_months = MONTHS_IN_YEAR;
> > +		if (!ctl.num_months)
> > +			ctl.num_months = MONTHS_IN_YEAR;
> >  		if (yflag) {
> >  			ctl.req.start_month = 1;	/* start from Jan */
> >  			ctl.header_year = 1;		/* print year number */
> > @@ -549,6 +549,9 @@ int main(int argc, char **argv)
> >  	else if (!ctl.months_in_row)
> >  		ctl.months_in_row = 1;
> >
> > +	if (!ctl.num_months)
> > +		ctl.num_months = 1;		/* display at least one month */
> > +
> >  	if (yflag || Yflag)
> >  		yearly(&ctl);
> >  	else
> > --
> > To unsubscribe from this list: send the line "unsubscribe
> > util-linux" in the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
> --
> To unsubscribe from this list: send the line "unsubscribe util-linux"
> in the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] cal: honor num_months when only a year argument

[Karel Zak]

On Wed, Jan 24, 2018 at 03:24:02PM +0100, Ruediger Meier wrote:
> On Monday 22 January 2018, J William Piggott wrote:
> > I don't know if this was an oversight or an overzealous
> > interpretation of POSIX. Just in case, I'll address the
> > POSIX possibility. POSIX description for cal(1) says:
> >
> >   If only the year operand is given, cal shall produce a
> >   calendar for all twelve months in the given calendar year.
> >
> > It also says that cal(1) has no options, so in that context
> > if an option is given then it should be expected to override
> > POSIX behavior.
> 
> We still don't need to fight against POSIX.
> 
> "cal -1" behaves like POSIX cal without options.
> "cal -3" behaves like POSIX except that it prints 3 months whereever  
> POSIX would print only 1.
> 
> > Before patched all of these command displayed a full year:
> > cal -1 2020
> > cal -3 2020
> > cal -n6 2020
> 
> Seriously, I find the new behavior quiet useless and unwanted. In past 

Well, old behavior is pretty strange too.

$ cal  -V
cal from util-linux 2.30.2

$ cal --three  2012
                               2012

        July                  August                September
Su Mo Tu We Th Fr Sa   Su Mo Tu We Th Fr Sa   Su Mo Tu We Th Fr Sa
                1  2       1  2  3  4  5  6                1  2  3
 3  4  5  6  7  8  9    7  8  9 10 11 12 13    4  5  6  7  8  9 10
10 11 12 13 14 15 16   14 15 16 17 18 19 20   11 12 13 14 15 16 17
17 18 19 20 21 22 23   21 22 23 24 25 26 27   18 19 20 21 22 23 24
24 25 26 27 28 29 30   28 29 30 31            25 26 27 28 29 30
31
       October               November               December
Su Mo Tu We Th Fr Sa   Su Mo Tu We Th Fr Sa   Su Mo Tu We Th Fr Sa
                   1          1  2  3  4  5                1  2  3
 2  3  4  5  6  7  8    6  7  8  9 10 11 12    4  5  6  7  8  9 10
 9 10 11 12 13 14 15   13 14 15 16 17 18 19   11 12 13 14 15 16 17
16 17 18 19 20 21 22   20 21 22 23 24 25 26   18 19 20 21 22 23 24
23 24 25 26 27 28 29   27 28 29 30            25 26 27 28 29 30 31
30 31
       January               February                 March
Su Mo Tu We Th Fr Sa   Su Mo Tu We Th Fr Sa   Su Mo Tu We Th Fr Sa
 1  2  3  4  5  6  7             1  2  3  4                1  2  3
 8  9 10 11 12 13 14    5  6  7  8  9 10 11    4  5  6  7  8  9 10
15 16 17 18 19 20 21   12 13 14 15 16 17 18   11 12 13 14 15 16 17
22 23 24 25 26 27 28   19 20 21 22 23 24 25   18 19 20 21 22 23 24
29 30 31               26 27 28 29            25 26 27 28 29 30 31

        April                   May                   June
Su Mo Tu We Th Fr Sa   Su Mo Tu We Th Fr Sa   Su Mo Tu We Th Fr Sa
 1  2  3  4  5  6  7          1  2  3  4  5                   1  2
 8  9 10 11 12 13 14    6  7  8  9 10 11 12    3  4  5  6  7  8  9
15 16 17 18 19 20 21   13 14 15 16 17 18 19   10 11 12 13 14 15 16
22 23 24 25 26 27 28   20 21 22 23 24 25 26   17 18 19 20 21 22 23
29 30                  27 28 29 30 31         24 25 26 27 28 29 30


... I don't understand why July etc.


> it seemed to work fine to have such alias in ~./profile
> 
>   alias cal="cal -3"

Nice.


> But now "cal -3 2019" always shows Dec, Jan, Feb. Can't believe that any 
> user finds this useful. At least it should output of the "current" 
> months of the given year. But I wouldn't change this at all. It's just 
> an annoying incompatible change without any benefit.

This is good point. I think -1 and -3 should print the current month
if the month is no specified.



    Karel


-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: [PATCH 1/2] cal: honor num_months when only a year argument

[Ruediger Meier]

On Tuesday 30 January 2018, Karel Zak wrote:
> On Wed, Jan 24, 2018 at 03:24:02PM +0100, Ruediger Meier wrote:
> > On Monday 22 January 2018, J William Piggott wrote:
> > > I don't know if this was an oversight or an overzealous
> > > interpretation of POSIX. Just in case, I'll address the
> > > POSIX possibility. POSIX description for cal(1) says:
> > >
> > >   If only the year operand is given, cal shall produce a
> > >   calendar for all twelve months in the given calendar year.
> > >
> > > It also says that cal(1) has no options, so in that context
> > > if an option is given then it should be expected to override
> > > POSIX behavior.
> >
> > We still don't need to fight against POSIX.
> >
> > "cal -1" behaves like POSIX cal without options.
> > "cal -3" behaves like POSIX except that it prints 3 months
> > whereever POSIX would print only 1.
> >
> > > Before patched all of these command displayed a full year:
> > > cal -1 2020
> > > cal -3 2020
> > > cal -n6 2020
> >
> > Seriously, I find the new behavior quiet useless and unwanted. In
> > past
>
> Well, old behavior is pretty strange too.

This is a bug introduced in v2.27-45-gccf3dd50c.

> $ cal  -V
> cal from util-linux 2.30.2
>
> $ cal --three  2012
>                                2012
>
>         July                  August                September
> Su Mo Tu We Th Fr Sa   Su Mo Tu We Th Fr Sa   Su Mo Tu We Th Fr Sa
>                 1  2       1  2  3  4  5  6                1  2  3
>  3  4  5  6  7  8  9    7  8  9 10 11 12 13    4  5  6  7  8  9 10
> 10 11 12 13 14 15 16   14 15 16 17 18 19 20   11 12 13 14 15 16 17
> 17 18 19 20 21 22 23   21 22 23 24 25 26 27   18 19 20 21 22 23 24
> 24 25 26 27 28 29 30   28 29 30 31            25 26 27 28 29 30
> 31
>        October               November               December
> Su Mo Tu We Th Fr Sa   Su Mo Tu We Th Fr Sa   Su Mo Tu We Th Fr Sa
>                    1          1  2  3  4  5                1  2  3
>  2  3  4  5  6  7  8    6  7  8  9 10 11 12    4  5  6  7  8  9 10
>  9 10 11 12 13 14 15   13 14 15 16 17 18 19   11 12 13 14 15 16 17
> 16 17 18 19 20 21 22   20 21 22 23 24 25 26   18 19 20 21 22 23 24
> 23 24 25 26 27 28 29   27 28 29 30            25 26 27 28 29 30 31
> 30 31
>        January               February                 March
> Su Mo Tu We Th Fr Sa   Su Mo Tu We Th Fr Sa   Su Mo Tu We Th Fr Sa
>  1  2  3  4  5  6  7             1  2  3  4                1  2  3
>  8  9 10 11 12 13 14    5  6  7  8  9 10 11    4  5  6  7  8  9 10
> 15 16 17 18 19 20 21   12 13 14 15 16 17 18   11 12 13 14 15 16 17
> 22 23 24 25 26 27 28   19 20 21 22 23 24 25   18 19 20 21 22 23 24
> 29 30 31               26 27 28 29            25 26 27 28 29 30 31
>
>         April                   May                   June
> Su Mo Tu We Th Fr Sa   Su Mo Tu We Th Fr Sa   Su Mo Tu We Th Fr Sa
>  1  2  3  4  5  6  7          1  2  3  4  5                   1  2
>  8  9 10 11 12 13 14    6  7  8  9 10 11 12    3  4  5  6  7  8  9
> 15 16 17 18 19 20 21   13 14 15 16 17 18 19   10 11 12 13 14 15 16
> 22 23 24 25 26 27 28   20 21 22 23 24 25 26   17 18 19 20 21 22 23
> 29 30                  27 28 29 30 31         24 25 26 27 28 29 30
>
>
> ... I don't understand why July etc.

It's because it shows a whole year with "today" in the middle.

$ cal -3  2012

does the same like

$ cal -n 6 --span 01 2012

That are 3 bugs in one :)

> > it seemed to work fine to have such alias in ~./profile
> >
> >   alias cal="cal -3"
>
> Nice.
>
> > But now "cal -3 2019" always shows Dec, Jan, Feb. Can't believe
> > that any user finds this useful. At least it should output of the
> > "current" months of the given year. But I wouldn't change this at
> > all. It's just an annoying incompatible change without any benefit.
>
> This is good point. I think -1 and -3 should print the current month
> if the month is no specified.
>
>
>
>     Karel