The dropdown doesn't help you with "fourth Thursday in November" though, and the calendar button launches a popup window that doesn't work. On archive.org at least -- may have worked at the time, but I disable popups, so...
Pretty sure my thought process was: need a Thanksgiving flight -> when is Thanksgiving this year? -> run cal(1) -> let's book.
Well, it's displaying the calendar for May of the year 16, not the year 2016. I guess it could require you to enter 0016, but I think the given behavior is reasonable.
You're right, correctness is important. And also wrong by thinking usability gets in the way of correctness
Usability helps with being correct
Vast majority of uses of cal apply to dates > 1900 (and I'd say a significant amount is > 2000)
'cal 16' should require a flag saying "Yes, I know what I'm doing, this is the actual year" and/or print the corresponding year for this century (being explicit, when printing, to which year it refers to)
> Vast majority of uses of cal apply to dates > 1900 (and I'd say a significant amount is > 2000)
According to what? Your use?
> 'cal 16' should require a flag saying "Yes, I know what I'm doing, this is the actual year" and/or print the corresponding year for this century (being explicit, when printing, to which year it refers to)
The command wants a year number as input. '16 is an ambiguous abbreviation that gains meaning only within context. As the command can't ask you what you meant, the default behaviour is sane.
According to wikipedia, cal was in First Edition Unix, back in 1971. You can assume it's been used in scripts and it would be hard to change default behavior now, or any time in the last 30 years for that matter.
I've used it myself in scripts to find Julian day numbers, to count days-within-months, etc. -- for old science data -- before there were more robust ways to do this stuff.
It's hard to insert DWIM behaviors into old command-line utilities, because "what I mean" is not clear.
Surely the correct thing would be a config setting to warn you if you're displaying a year in the past (or a year before one that you specify - e.g. 100). Meh, even `cal 8` displays the year prominently at the top.
Another useful command line service I use almost daily (using a rather wide terminal):
$ curl wttr.in/94035
My most frequently used option for cal on GNU/Linux is "-3". It shows the current, previous, and next month with the current day highlighted, which are usually all the information I need.
$ cal -3
April 2016 May 2016 June 2016
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 7 1 2 3 4
3 4 5 6 7 8 9 8 9 10 11 12 13 14 5 6 7 8 9 10 11
10 11 12 13 14 15 16 15 16 17 18 19 20 21 12 13 14 15 16 17 18
17 18 19 20 21 22 23 22 23 24 25 26 27 28 19 20 21 22 23 24 25
24 25 26 27 28 29 30 29 30 31 26 27 28 29 30
FTA: I’d be really excited to hear all the use cases for gcal one can come up with. Seems really suited for a TODO list manager or to never forget a birthday again.
$ man calendar
CALENDAR(1) General Commands Manual CALENDAR(1)
NAME
calendar - reminder service
SYNOPSIS
calendar [-abw] [-A num] [-B num] [-f calendarfile] [-t [[[cc]yy]mm]dd]
DESCRIPTION
The calendar utility checks the current directory or the directory
specified by the CALENDAR_DIR environment variable for a file named
calendar and displays lines that begin with either today's date or
tomorrow's. On Fridays, events on Friday through Monday are displayed.
[...]
A lot of apps pay attention to the name you run them as—for instance, making sure the correct name is reported when you list the command line switches. But this is definitely the most extreme case I'm aware of.
Yup, FreeBSD has cal and ncal. Latter has additional options for printing week numbers, date of Easter, etc., though I find it kind of hard to get used to transposed row/col output.
Good ol cal! Circa 1998 my first homebrew web ui date picker input was just cal output redressed with html links ... And we were thankful for what we had!
Huh, despite being the "GNU" calendar program, gcal is in fact generally named gcal on GNU/Linux. On my Debian GNU/Linux machine, /usr/bin/cal is from bsdmainutils, and gcal is in its own package (as with Homebrew).
M-x calendar is my go-to cal substitute on platforms that lack cal (coughWindowscough). Though, now that Windows 10 has a Linux subsystem, I might just use cal everywhere.
The output is the same as just "cal" for me, so I had to see what it's about: It puts Monday as the first day of the week. I guess that is because I use the German date locale. Seems that the US uses Sunday as the first day of the week in calendars and such, but does it make any difference beyond those? Don't people "feel" that Monday is the first day of the week because the weekend is over and they have to get back to work?
I feel Sunday is the start of the week because that's what I've been seeing on calendars my whole life. I do bundle Mon-Fri and Sat-Sun into "weekdays" and "weekend" in my head, but when I visualize a week in my head, it always starts on Sunday.
> Don't people "feel" that Monday is the first day of the week because the weekend is over and they have to get back to work?
No, I feel that Sunday is the day of rest I start my week with, then I do some work, and finally I rest again: in that way my day is a microcosm of my week (and one might think that in a more primitive society my year would be a macrocosm, as I did more work spring-summer than during the winter).
I personally detest calendars which display Monday as the first day of the week, and am genuinely curious why ISO chose that.
I personally detest calendars which display Sunday as the first day of the week, since it's incorrect according to one of the earliest memories I have -- my mum teaching my this rhyme:
Solomon Grundy,
Born on a Monday,
Christened on Tuesday,
Married on Wednesday,
Took ill on Thursday,
Grew worse on Friday,
Died on Saturday,
Buried on Sunday,
That was the end,
Of Solomon Grundy.
Also, Saturday and Sunday are the weekend, not the week-edges.
--
There's a bug in cal -- the man page says "-M" makes the week start on Monday, but my version doesn't accepthe argument.
I find it quite confusing when calendars mess this up. I once booked a flight on the wrong day, because I somehow switched to the American localization of the airline's website part-way through the booking process.
> Also, Saturday and Sunday are the weekend, not the week-edges.
You might be interested to know that in Israel the work week starts on Sunday, not Monday. Friday and Saturday are the weekend.
That might just be a factoid, except that the Jewish Sabbath was the origin of the weekend concept. It changed in countries with a strong Christian influence so that Monday because the first day.
It never changed in the US because the Jewish workweek had a stronger influence there than the Christian one.
> I personally detest calendars which display Sunday as the first day of the week
And I personally find calendars that start on Monday quite bizarre since it's obviously incorrect historically.
> I personally detest calendars which display Monday as the first day of the week, and am genuinely curious why ISO chose that.
I think ISO chose it because there was considerable difference between countries as to what the first day of the week in usual calendar presentation was when ISO 8601 was being considered, they needed something consistent, and it just happened to shake out to Monday.
Looking at https://en.wikipedia.org/wiki/Names_of_the_days_of_the_week#..., it appears that almost every language which numbers the days of the week starts on Sunday, with the exception of some Slavic languages (which use Monday) and Swahili (which uses Saturday).
The -M and -S options are extensions that are patched into the Debian ports of the FreeBSD ncal command. They have not been contributed back to the original, and some of the weekday calculations (that involve querying what the current locale's idea of the first day of the week is using the SUS2 nl_langinfo() library function) are tied to GNU libc.
cal is great, but I never remember it exists. I always (OSX) go up to the menubar datetime, get annoyed that there's no kind of simple calendar underneath it (just wrap cal!), then go hunting for Google Calendar. I guess I just don't think of that kind of program as a built-in command-line one.
I feel you, having used Linux (and I guess Windows) a lot longer than OSX this gets me every time, and every time I wonder why such a simple and useful feature was omitted.
"Note that output from .bashrc stuffs up rsync and scp, in case you use them. Enclose the lot in { .... } >&2"
I call a shell script from my .bashrc so does this have the same effect? I'll take this advice and wrap the script. I don't use scp or rsync but possible could at some time, thanks @emmelaich.
Killer feature of gcal for me is that by default it highlights the current day. Didn't know about `gcal .`, which is very convenient to know; I used to do `gcal 2016` if I needed to see prev/next months.
