Using yearistype requires "." in $PATH

Robert Elz kre at munnari.OZ.AU
Mon Aug 7 22:31:03 UTC 2000


    Date:        Mon, 7 Aug 2000 15:32:54 -0400 
    From:        "Olson, Arthur David (NCI)" <olsona at dc37a.nci.nih.gov>
    Message-ID:  <4E0F9DDCA724D411B2120008C75DB71DD0F3F2 at nihexchange2.nih.gov>

  | Maybe the first step is to change the Makefile line that reads
  | 	cp zic zdump $(ETCDIR)/.
  | to read
  | 	cp yearistype zdump zic $(ETCDIR)/.

Oh good, I was beginning to wonder if my message actually left here...
I guess the tz list doesn't send messages back to the originator or
something.

Personally, I don't think that would be the best solution, yearistype
is hardly the kind of utility that anyone is ever going to want to run
by hand, nor is it really very likely to be useful for scripts or similar.
Its sole purpose is for use by zic.   If it were to be installed anywhere
it would go in a libexec type directory, which doesn't help the current
problem, as those don't usually appear in people's paths either.

Perhaps a solution might just be to make the current yearistype a builtin
function in zic instead of a separate script?   That is, without -y, simply
implement what is in yearistype.sh in C and build it in.   But leave -y
there to allow people to provide a replacement script if they need to be
able to modify the rules for some special case.  I think we've had enough
experience with the current script now to know that it has been covering all
the known cases for years without anyone needing to change it.

Then we wouldn't need to worry about what is in PATH - anyone using -y
can easily specify an arg that can be found, and even easier, will know
what the problem is if zic complains that it can't run the supplied arg.

Further, it would forever end the debate about whether yearistype.sh belongs
in tzcode (since it is code) or in tzdata (since it could theoretically at
least need to vary depending upon changes in the data files).

kre




More information about the tz mailing list