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
note.
--
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