200(0) Ancient UNIX Licenses

Michael Sokolov msokolov at meson.jpsystems.com
Wed Jan 5 01:39:51 AEST 2000

norman at nose.cita.utoronto.ca wrote:

> Warren's note reminds me of a few other Y2K bugs I've spotted that affect
> ancient UNIX:

Would you please avoid that term? It is offensive to those for whom Kernighan/
Ritchie/Thompson/Berkeley UNIX is the primary and sole computing platform.
Thank you.

> - date: no way to set the date past 1999 unless in the present year,
> because two-digit input.
> - at and atrun: commands are stored in the spooling directory with names
> of the form YY.DDD.HHMM.xx, where xx is a unique number.  This one is
> trickier to fix, because the filename is already exactly 14 characters,
> so there's no room for expansion.  (On V10, I just rewrote the programs
> to use a simple UNIX time expressed as a decimal number.  A simpler solution
> might be to print the year in hex.)

Both Y2K bugs have been fixed in the UNIX master source tree a couple of weeks
ago, will appear on the 4.3-QJ0b tape. For details, send a subscription request
to quasijarus-request at meson.jpsystems.com.

> - Perhaps least consequential and most amusing: nroff and troff store the
> year in a number register.  The manual says it contains `the last two
> digits of the year,' and many macro packages assume that is true, but the
> truth is that it contains (year-1900), the same as tm_year.  So, for example,
> when I ran man on New Year's Day, I was told that the manual page had been
> printed on 1/1/100.
> I was about to fix the various troff macro packages when I noticed that
> the manual implied that I shouldn't.  I asked Brian Kernighan for an opinion
> (since the code and the manual were both last touched by him); he thinks the
> best view is that the manual is just wrong and the macro packages should be
> fixed.  \n(yr is a read-write register, so `.nr yr \n(yr+1900' is probably
> the easiest fix, though Brian points out that it's not always the right one
> (maybe you really wanted a two-digit year).  If anyone is interested I can
> pass along a more detailed note from Brian.

OK, haven't hit that one yet, will look. Please do pass along B. W. Kernighan's

Michael Sokolov				Harhan Computer Operation Facility
Special Agent				615 N GOOD LATIMER EXPY #4
International Free Computing Task Force	DALLAS TX 75204-5852 USA
					Phone: +1-214-824-7693
					ARPA INET: msokolov at meson.jpsystems.com

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id DAA34078
	for pups-liszt; Wed, 5 Jan 2000 03:27:07 +1100 (EST)

More information about the TUHS mailing list