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