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)
|
