From owner-cvs-usrbin  Sat Dec 13 01:57:39 1997
Return-Path: <owner-cvs-usrbin>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id BAA09709
          for cvs-usrbin-outgoing; Sat, 13 Dec 1997 01:57:39 -0800 (PST)
          (envelope-from owner-cvs-usrbin)
Received: from rvc1.informatik.ba-stuttgart.de (rvc1.informatik.ba-stuttgart.de [141.31.112.22])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA09698;
          Sat, 13 Dec 1997 01:57:30 -0800 (PST)
          (envelope-from helbig@Informatik.BA-Stuttgart.DE)
Received: (from helbig@localhost)
	by rvc1.informatik.ba-stuttgart.de (8.8.8/8.8.5) id KAA00340;
	Sat, 13 Dec 1997 10:57:11 +0100 (MET)
From: Wolfgang Helbig <helbig@Informatik.BA-Stuttgart.DE>
Message-Id: <199712130957.KAA00340@rvc1.informatik.ba-stuttgart.de>
Subject: Re: cvs commit: src/usr.bin/cal cal.1
In-Reply-To: <199712130647.WAA03452@precipice.shockwave.com> from Paul Traina at "Dec 12, 97 10:47:14 pm"
To: pst@shockwave.com (Paul Traina)
Date: Sat, 13 Dec 1997 10:57:11 +0100 (MET)
Cc: helbig@Informatik.BA-Stuttgart.DE, adam@veda.is, helbig@FreeBSD.ORG,
        cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG,
        cvs-usrbin@FreeBSD.ORG
X-Mailer: ELM [version 2.4ME+ PL30 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-cvs-usrbin@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> I think ncal as a port would be a mighty fine thing.  In fact, I think ncal

OK, you won :-)
But ...
ncal(1) depends on the little library /usr/src/lib/libcalendar
which I recently put into -current, so ncal wouldn't build in
FreeBSD-2.2.x unless the library is ported as well.

> would be just fine if the default mode was cal(1) compatible.  I have no 
> problems with extending unix, but I do have a teensy one with changing 
> defaults that have existed since the dawn of history (1970.1.1 or Jan 1 1970 
> for us
> happy-go-lucky Americans).
> 
> I hate cal(1), but I'm used to its stupidities now.  While I can adapt,
> silly programs that call it for output may not.

I get that point. So how about this: If called "cal", "ncal" would behave
like "cal", otherwise like "ncal"--implemented via a hard link from
/usr/bin/cal to /usr/bin/ncal.
Is that acceptable?

Wolfgang