"leapseconds.awk" no longer has a CRLF problem per se. That is, just as long as we don't do something silly like printing strings with CRs in them (which we used to do but don't do now). At the time I reported the CRLF problem on 2019-07-27 at 05:47:10 UTC, leapseconds.awk was still using the comments as data to print the date of the zic "leap" directives it generates. (https://mm.icann.org/pipermail/tz/2019-July/028382.html) We don't do that anymore.  The actual NTP timestamp datum is now being used to create the necessary date string thanks to Dr. Eggert's implementation of Dennis C. Ferguson's sstamp_to_ymdhMs() AWK function. (https://mm.icann.org/pipermail/tz/2019-September/028495.html) The two remaining string variables we use with CRs in them, the update and expiry NTP timestamps, are processed arithmetically before their values are printed.  This eliminates the CRs as an issue with them. I still think it would be a good idea to use int() or strtonum() when they are read because the CRs *are* there.  There are no leading zeroes to preserve (which was the primary  objection I heard for not using int()). (https://blog.longnow.org/02013/12/31/long-now-years-five-digit-dates-and-10k...) (Seven thousand nine hundred and eighty years from now...?  This is farther in the future than the discovery of agriculture is in the past...) The sub() on $0 is unnecessary (and possibly bad practice). (I could argue on either side of the issue.) $ git diff leapseconds.awk diff --git a/leapseconds.awk b/leapseconds.awk index 924ade9..0e3eb1a 100755 --- a/leapseconds.awk +++ b/leapseconds.awk @@ -71,15 +71,13 @@ BEGIN {    sstamp_init()  } -# In case the input has CRLF form a la NIST. -{ sub(/\r$/, "") } -  /^#[ \t]*[Uu]pdated through/ || /^#[ \t]*[Ff]ile expires on/ {      last_lines = last_lines $0 "\n"  } -/^#[$][ \t]/ { updated = $2 } -/^#[@][ \t]/ { expires = $2 } +# In case the input has CRLF form a la NIST. +/^#[$][ \t]/ { updated = int( $2 ) } +/^#[@][ \t]/ { expires = int( $2 ) }  /^[ \t]*#/ { next }