* [PATCH 1/2] cal: honor num_months when only a year argument
@ 2018-01-22 20:05 J William Piggott
2018-01-22 20:07 ` [PATCH 2/2] cal: do not set months_in_row with -3 option J William Piggott
` (2 more replies)
0 siblings, 3 replies; 9+ messages in thread
From: J William Piggott @ 2018-01-22 20:05 UTC (permalink / raw)
To: Karel Zak; +Cc: util-linux
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
^ permalink raw reply related [flat|nested] 9+ messages in thread
* [PATCH 2/2] cal: do not set months_in_row with -3 option
2018-01-22 20:05 [PATCH 1/2] cal: honor num_months when only a year argument J William Piggott
@ 2018-01-22 20:07 ` J William Piggott
2018-01-24 13:25 ` Karel Zak
2018-01-24 12:54 ` [PATCH 1/2] cal: honor num_months when only a year argument Karel Zak
2018-01-24 14:24 ` Ruediger Meier
2 siblings, 1 reply; 9+ messages in thread
From: J William Piggott @ 2018-01-22 20:07 UTC (permalink / raw)
To: Karel Zak; +Cc: util-linux
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 */
^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH 1/2] cal: honor num_months when only a year argument
2018-01-22 20:05 [PATCH 1/2] cal: honor num_months when only a year argument J William Piggott
2018-01-22 20:07 ` [PATCH 2/2] cal: do not set months_in_row with -3 option J William Piggott
@ 2018-01-24 12:54 ` Karel Zak
2018-01-24 15:22 ` J William Piggott
2018-01-24 14:24 ` Ruediger Meier
2 siblings, 1 reply; 9+ messages in thread
From: Karel Zak @ 2018-01-24 12:54 UTC (permalink / raw)
To: J William Piggott; +Cc: util-linux
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
^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH 2/2] cal: do not set months_in_row with -3 option
2018-01-22 20:07 ` [PATCH 2/2] cal: do not set months_in_row with -3 option J William Piggott
@ 2018-01-24 13:25 ` Karel Zak
0 siblings, 0 replies; 9+ messages in thread
From: Karel Zak @ 2018-01-24 13:25 UTC (permalink / raw)
To: J William Piggott; +Cc: util-linux
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)
^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH 1/2] cal: honor num_months when only a year argument
2018-01-22 20:05 [PATCH 1/2] cal: honor num_months when only a year argument J William Piggott
2018-01-22 20:07 ` [PATCH 2/2] cal: do not set months_in_row with -3 option J William Piggott
2018-01-24 12:54 ` [PATCH 1/2] cal: honor num_months when only a year argument Karel Zak
@ 2018-01-24 14:24 ` Ruediger Meier
2018-01-24 15:33 ` Ruediger Meier
2018-01-30 10:44 ` Karel Zak
2 siblings, 2 replies; 9+ messages in thread
From: Ruediger Meier @ 2018-01-24 14:24 UTC (permalink / raw)
To: J William Piggott; +Cc: Karel Zak, util-linux
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 1/2] cal: honor num_months when only a year argument
2018-01-24 12:54 ` [PATCH 1/2] cal: honor num_months when only a year argument Karel Zak
@ 2018-01-24 15:22 ` J William Piggott
0 siblings, 0 replies; 9+ messages in thread
From: J William Piggott @ 2018-01-24 15:22 UTC (permalink / raw)
To: Karel Zak; +Cc: util-linux
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
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 1/2] cal: honor num_months when only a year argument
2018-01-24 14:24 ` Ruediger Meier
@ 2018-01-24 15:33 ` Ruediger Meier
2018-01-30 10:44 ` Karel Zak
1 sibling, 0 replies; 9+ messages in thread
From: Ruediger Meier @ 2018-01-24 15:33 UTC (permalink / raw)
To: J William Piggott; +Cc: Karel Zak, util-linux, Deiz
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 1/2] cal: honor num_months when only a year argument
2018-01-24 14:24 ` Ruediger Meier
2018-01-24 15:33 ` Ruediger Meier
@ 2018-01-30 10:44 ` Karel Zak
2018-01-30 12:05 ` Ruediger Meier
1 sibling, 1 reply; 9+ messages in thread
From: Karel Zak @ 2018-01-30 10:44 UTC (permalink / raw)
To: Ruediger Meier; +Cc: J William Piggott, util-linux
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 1/2] cal: honor num_months when only a year argument
2018-01-30 10:44 ` Karel Zak
@ 2018-01-30 12:05 ` Ruediger Meier
0 siblings, 0 replies; 9+ messages in thread
From: Ruediger Meier @ 2018-01-30 12:05 UTC (permalink / raw)
To: Karel Zak; +Cc: J William Piggott, util-linux
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
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2018-01-30 12:05 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-01-22 20:05 [PATCH 1/2] cal: honor num_months when only a year argument J William Piggott
2018-01-22 20:07 ` [PATCH 2/2] cal: do not set months_in_row with -3 option J William Piggott
2018-01-24 13:25 ` Karel Zak
2018-01-24 12:54 ` [PATCH 1/2] cal: honor num_months when only a year argument Karel Zak
2018-01-24 15:22 ` J William Piggott
2018-01-24 14:24 ` Ruediger Meier
2018-01-24 15:33 ` Ruediger Meier
2018-01-30 10:44 ` Karel Zak
2018-01-30 12:05 ` Ruediger Meier
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).