Subj : Outbound Report To : mark lewis From : Michael Dukelsky Date : Tue Jun 16 2020 13:31:42 Hello mark, Monday June 15 2020, mark lewis wrote to Sean Rima: SR>> I think the issue is that bash changed something and broke the SR>> code. ml> possible... the system the script was developed on is using ml> GNU bash, version 4.4.20(1)-release (x86_64-pc-linux-gnu) Here it is GNU bash, version 4.2.46(2)-release (x86_64-redhat-linux-gnu). SR>> I am holding off with my point echomail, which is basically the SR>> same groups here anyway. I will throw a fileecho into the mix and SR>> see what happens ml> points and TICs should be fine... the system the script was developed ml> on is a FDN HUB as well as an echomail star with points... I compared the output of showold.pl and waitingoutmail. I will give only a small piece of thier output. showold.pl: +------------------+--------+-----------+-----------+-----------+ | Node | Days | NetMail | EchoMail | Files | +------------------+--------+-----------+-----------+-----------+ | 2:460/58 | 3 | 0 | 231525 | 417.0784M | waitingoutmail: d 2:460/58@out (01cc003a) : 252 files : 5051 days 17:38:25 Next Delivery Attempt: 2020-06-16 13:19:59 +0300 Last Delivery Status: No route to host Here we see that the opinion of the two programs on the age of the problem is quite different. For showold.pl it is 3 days and for waitingoutmail it is 5051 days. The reason of the difference is simple: waitingoutmail considers filetime of all files and showold.pl considers filetime of .TICs but does not take into account filetime of the files the .TICs refer to. For me it is interesting to know for how long the link has not fetched his mail and I don't care if somebody has hatched files from the year 2017. That's why 5051 days is not the information I wait from the program. But Last Delivery Status is very useful. Michael .... node (at) f1042 (dot) ru --- GoldED+/LNX 1.1.5-b20170303 * Origin: Moscow, Russia (2:5020/1042) .