Hello Nick!

03 Oct 26 17:06, you wrote to Kees van Eeten:

Send the Patch to Andrew Leary, I think he still maintains the
distributed sources.

I did that before even posting about it here. ;)

I did get your email about this; it's on my list of things to get to soon(ish).

Maybe your patch should have its own parameter to activate, so it
will
not change the the output currently produced by -t.

The current behavior was setup to mimic what the original DOS MakeNL from Ben Baker did.

Maybe. That's up to the maintainer, I suppose.

IMO, I don't really see enough reason to make a new parameter, though, unless it would be an option or extension to '-t' for 'verbose', or something in those lines. It basically does the exact same thing it
did, just outputs more information in test mode. Rather than "there is
an error..." the patch makes it "there is an error, and this is what
it is ..."

I can see the value in having more information about what the errors are as soon as the segment is received.

Just as well, it doesn't need to be changed at all, really. If that
was the original way it was intended, so be it. I didn't understand
why it wouldn't tell you what the actual error was, so I made it do
so.

When I get a few minutes to look at it further, I want to look at a few things in MakeNL anyway. There was a proposal years ago to add password protection to nodelist segment submissions; I've been thinking about actually implementing something along those lines. Currently there is no check on the origin of a submitted segment file; if it has the correct filename and arrives in the coordinator's inbound, it will be imported. If a troublemaker discovers the segment filename used, they could potentially submit a modified segment file to add bogus nodelist entries, delete valid nodes, change the coordinator of a net or region, etc. I admit it's unlikely these days, but it could happen.

If people already have their own workarounds in place (ie. running it
in process mode instead of even using test mode, or using a script of
some sort to verify what the error actually is), then let it be. ;)

I'm not making any promises, but your patch could be included in a future version.

Andrew

---
* Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)

Hello Andrew,

On 05 Oct 26 02:22, you wrote to Nick Boel:

When I get a few minutes to look at it further, I want to look at a
few things in MakeNL anyway. There was a proposal years ago to add password protection to nodelist segment submissions; I've been
thinking about actually implementing something along those lines. Currently there is no check on the origin of a submitted segment file;
if it has the correct filename and arrives in the coordinator's
inbound, it will be imported.

We already have something for that: the TIC system. When I was RC28 I used to send my segments to Ward accompanied by a .TIC file. So his file manager could move it from the secure inbound to the proper directory for safe processing.


Cheers, Michiel

--- GoldED+/W32-MINGW 2.0.0-b20260928
* Origin: http://www.vlist.eu (2:280/5555)

Hey Andrew!

On Mon, Oct 05 2026 02:22:20 -0400, you wrote:

I did get your email about this; it's on my list of things to get to soon(ish).

Yep, I can confirm you also responded that you would take a look. It's no worries at all.

Regards,
Nick

... Take my advice, I don't use it anyway.
--- AmberEdit/linux 0.9.0
* Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (1:154/10)

On 2026 Oct 05 22:09:20, you wrote to Andrew Leary:

We already have something for that: the TIC system. When I was RC28 I used to send my segments to Ward accompanied by a .TIC file. So his file manager
could move it from the secure inbound to the proper directory for safe processing.

that made me blink a few times... i don't know that i've ever heard of anyone using tic/raid/hatch/etc to send nodelist segments upstream... i can imagine some script and settings work is needed to prevent makenl and similar from using the normal file attached netmail method and to do all the things needed for hatching the file upstream...

)\/(ark

"The soul of a small kitten in the body of a mighty dragon. Look on my majesty, ye mighty, and despair! Or bring me catnip. Your choice. Oooh, a shiny thing!"
... It is twice as hard to crush a half-truth as it is a whole lie.
---
* Origin: (1:3634/12.73)

On 2026 Oct 05 21:09:42, you wrote to me:

On 05 Oct 26 19:18:04, Mark Lewis said the following to Michiel Van Der Vlist:

that made me blink a few times... i don't know that i've ever heard of
anyo using tic/raid/hatch/etc to send nodelist segments upstream... i
can imagin some script and settings work is needed to prevent makenl
and similar from using the normal file attached netmail method and to
do all the things need for hatching the file upstream...

Thats how it works amongst ZC's.

very interesting... who said you can't teach old dogs new tricks ;)

)\/(ark

"The soul of a small kitten in the body of a mighty dragon. Look on my majesty, ye mighty, and despair! Or bring me catnip. Your choice. Oooh, a shiny thing!"
... A cat is a friend who will never betray you.
---
* Origin: (1:3634/12.73)

Andrew,

When I get a few minutes to look at it further, I want to look at a few things in MakeNL anyway. There was a proposal years ago to add password protection to nodelist segment submissions; I've been thinking about actually implementing something along those lines. Currently there is no check on the origin of a submitted segment file; if it has the correct filename and arrives in the coordinator's inbound, it will be imported.
If a troublemaker discovers the segment filename used, they could potentially submit a modified segment file to add bogus nodelist entries, delete valid nodes, change the coordinator of a net or region, etc. I
admit it's unlikely these days, but it could happen.

My take on this:

1) It has been attempted in the 1990-ies, never worked. People have also sent
in bogus Fidonews-articlea mind you
2) Sessions are password protected. Try to send a bogus segment and:
a} it will be discovered
b} the node attempting this, is a goner
c} Don't you love things like the DAILY-nodelists? They can be
re-issued daily to recover damage
3) I became ZC for the first time in October 1994. 1666 nodelists later I
don't see the use
4) Everybody in life is entitled to some fun, so if you want to develop
something like this, go ahead. No-one will use it. Top-level *Cs are
already happy there's someone willing/available to do the job
5) If it ain't broke, don't fix it.
6) The correct file-names for the REGION-files for both Z1 and Z2 are
published daily. It's no secret.

\%/@rd

--- DB4 - 20260902
* Origin: May the Source be with you (2:292/854)

Hello Nick!

05 Oct 26 15:02, you wrote to me:

implementing something along those lines. Currently there is no
check on t origin of a submitted segment file; if it has the
correct filename and arri in the coordinator's inbound, it will be
imported. If a troublemaker

Then the Coordinator is imcompetent.

Segments are received via secure BinkD sessions already password protected. If a file is received via unsecure means, it is moved to a directory here for manual inspection.

Yes, the secure inbound is a good first step. However, in most cases there is no way to tell which of your secure links sent a file, other than going through your mailer log files.

Andrew

---
* Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)

Hello Michiel!

05 Oct 26 22:09, you wrote to me:

We already have something for that: the TIC system. When I was RC28 I
used to send my segments to Ward accompanied by a .TIC file. So his
file manager could move it from the secure inbound to the proper
directory for safe processing.

This is probably the easiest way to do it. This would enable validation of the node sending the file, along with checking the .TIC file password and the file CRC.

Andrew

---
* Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)

Hello mark!

05 Oct 26 19:18, you wrote to Michiel van der Vlist:

that made me blink a few times... i don't know that i've ever heard of anyone using tic/raid/hatch/etc to send nodelist segments upstream...
i can imagine some script and settings work is needed to prevent
makenl and similar from using the normal file attached netmail method
and to do all the things needed for hatching the file upstream...

All that would really be required in the case of MakeNL is commenting out the SUBMIT entry in the control file. Then the coordinator would need to use some means of detecting that a new segment was created (such as the return code from MakeNL), and then hatch the file in the correct file echo.

Andrew

---
* Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)

Hello Ward!

06 Oct 26 09:35, you wrote to me:

When I get a few minutes to look at it further, I want to look at
a few things in MakeNL anyway. There was a proposal years ago to
add password protection to nodelist segment submissions; I've been
thinking about actually implementing something along those lines.
Currently there is no check on the origin of a submitted segment

file; if it has the correct filename and arrives in the

coordinator's inbound, it will be imported. If a troublemaker
discovers the segment filename used, they could potentially submit
a modified segment file to add bogus nodelist entries, delete
valid nodes, change the coordinator of a net or region, etc. I

admit it's unlikely these days, but it could happen.

My take on this:

1) It has been attempted in the 1990-ies, never worked. People have
also sent
in bogus Fidonews-articlea mind you

Security through obscurity is never very secure.

2) Sessions are password protected. Try to send a bogus segment and:
a} it will be discovered
b} the node attempting this, is a goner
c} Don't you love things like the DAILY-nodelists? They can be
re-issued daily to recover damage

I never understood the mindset of the folks that used to create mail bombs, either. That doesn't mean that we shouldn't attempt to secure things.

3) I became ZC for the first time in October 1994. 1666 nodelists
later I
don't see the use

I admit that it's unlikely that anyone would care enough to try to disrupt the nodelist process these days.

4) Everybody in life is entitled to some fun, so if you want to
develop
something like this, go ahead. No-one will use it. Top-level *Cs
are
already happy there's someone willing/available to do the job.

I doubt that much will happen on that front, as there are several more important things that will take considerable time.

5) If it ain't broke, don't fix it.
6) The correct file-names for the REGION-files for both Z1 and Z2 are
published daily. It's no secret.

Really? I know the filename that I send Nick each week is NOT the one that gets posted in Z1C. I would imagine that the same is the case for the other RCs in Zone 1.

Andrew

---
* Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)

On 07 Oct 26 05:50:48, Andrew Leary said the following to Nick Andre:

Yes, the secure inbound is a good first step. However, in most cases there no way to tell which of your secure links sent a file, other than going through your mailer log files.

I'm very confused what you mean by this.

Secure things get processed. Unsecure things do not.

Each filename is unique to the RC.

I do not process what does not match both criteria.

What am I missing here?

Nick

--- Renegade vY2Ka2
* Origin: Joey, do you like movies about gladiators? (1:229/426)

Hello Andrew,

On 07 Oct 26 05:57, you wrote to me:

We already have something for that: the TIC system. When I was
RC28 I used to send my segments to Ward accompanied by a .TIC
file. So his file manager could move it from the secure inbound
to the proper directory for safe processing.

This is probably the easiest way to do it. This would enable
validation of the node sending the file, along with checking the .TIC
file password and the file CRC.

I do not recall aal the details but I do know that I have been doing it this way since I became 28 pointlist keeper for sending the R28 point segment to the Z2PK

Cheers, Michiel

--- GoldED+/W32-MINGW 2.0.0-b20260928
* Origin: http://www.vlist.eu (2:280/5555)

Hello Andrew,

On 07 Oct 26 06:19, you wrote to mark lewis:

that made me blink a few times... i don't know that i've ever
heard of anyone using tic/raid/hatch/etc to send nodelist
segments upstream... i can imagine some script and settings work
is needed to prevent makenl and similar from using the normal
file attached netmail method and to do all the things needed for
hatching the file upstream...

All that would really be required in the case of MakeNL is commenting
out the SUBMIT entry in the control file. Then the coordinator would
need to use some means of detecting that a new segment was created
(such as the return code from MakeNL), and then hatch the file in the correct file echo.

As I said, I do not recall al the details. What I remember is that all I used MakeNl for is processing the segments. All the rest was done in another way. When segmenst came in with a .TIC file the filemanger moved it to the proper directory. When not it was moved by a simple script on arrival of the matching file name. Makenl only used the files from that particular directory. Sending the file upostream was done by another script. Indeed the SUBMIT fucntion of MakenL was not used.


Cheers, Michiel

--- GoldED+/W32-MINGW 2.0.0-b20260928
* Origin: http://www.vlist.eu (2:280/5555)

Hello Andrew,

On 07 Oct 26 05:50, you wrote to Nick Andre:

Segments are received via secure BinkD sessions already password
protected. If a file is received via unsecure means, it is moved
to a directory here for manual inspection.

Yes, the secure inbound is a good first step. However, in most cases there is no way to tell which of your secure links sent a file, other
than going through your mailer log files.

Finding the purpetrator is easy enough. Making sure that he/she never does it again is not that hard either....


Cheers, Michiel

--- GoldED+/W32-MINGW 2.0.0-b20260928
* Origin: http://www.vlist.eu (2:280/5555)

Hello Andrew,

On 07 Oct 26 06:30, you wrote to Ward Dossche:

I never understood the mindset of the folks that used to create mail bombs, either. That doesn't mean that we shouldn't attempt to secure things.

Once I got a mail bomb. From someone who had the security level to pass all the security barriers. Fotunatek there was little damage. The Fido system ran on a dedicated hard drive that overflowed and there is stopped. of course the bad guy (a fellow FTSC member) never got a chance to do it again. i wrote a Fidonews article about it.

You can seal the door to the cockpit, but it does not help when the evil is already inside. As happened recently when a copilot went berserk...


Cheers, Michiel

--- GoldED+/W32-MINGW 2.0.0-b20260928
* Origin: http://www.vlist.eu (2:280/5555)

Hey All!

If someone running the latest makenl can verify my findings, I would appreciate it:

https://github.com/zoomosis/makenl/issues/7

Steps to reproduce:

1) Purposely cause an error in one of your segments
2) Copy it to /received (or the "new" process directory) and/or keep a copy of it in the master directory (ie. try both).
3) Run "makenl <control file> -t" for "test mode".
4) Don't forget to revert any changes back to normal after testing.

In my test cases, no errors were found at all using the "test" mode (I had multiple errors that were there for months, and I don't paste my logs for my 'othernet' like I do for Fidonet, so it went unnoticed). It wasn't until processing manually where I noticed the problems, after being notified that something was wrong.

Surprisingly, it didn't take long for chatgpt to indicate `"-t" sets mustbenew = 1, so openlist() doesn't even search UpdateDir or MasterDir.`

I seem to have an easy fix in procfile.c (line 99), tested during this previous weekly run that nothing else was affected, and test mode now works as expected:


```
- if (ShouldProcess == 0 && MergeOutFILE == 0) /* Process only
+ if (ShouldProcess == 0 && !JustTest && MergeOutFILE == 0) /* Process only
new files */
mustbenew = 1;
else
mustbenew = 0;
```

Regards,
Nick

... Sarcasm, because beating people up is illegal.
--- AmberEdit/linux 0.9.0
* Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (1:154/10)

Hi Nick,

On 2026-10-01 07:53:38, you wrote to All:

If someone running the latest makenl can verify my findings, I would appreciate it:

https://github.com/zoomosis/makenl/issues/7

Steps to reproduce:

1) Purposely cause an error in one of your segments
2) Copy it to /received (or the "new" process directory) and/or keep a copy of
it in the master directory (ie. try both). 3) Run "makenl <control file> -t"
for "test mode". 4) Don't forget to revert any changes back to normal after
testing.

In my test cases, no errors were found at all using the "test" mode (I had multiple errors that were there for months, and I don't paste my logs for my
'othernet' like I do for Fidonet, so it went unnoticed). It wasn't until processing manually where I noticed the problems, after being notified that
something was wrong.

For the AmigaNet nodelist I found out a long time ago the test mode is useless. For "testing" I just generate the nodelist for real (but don't hatch it of course)...


Bye, Wilfred.

--- FMail-lnx64 2.3.4.1-B20260520
* Origin: FMail development HQ (2:280/464)

Hey Wilfred!

On Thu, Oct 01 2026 14:59:36 +0200, you wrote:

For the AmigaNet nodelist I found out a long time ago the test mode is useless. For "testing" I just generate the nodelist for real (but don't hatch it of course)...

Did you ever report it?

Did you try my fix?

Regards,
Nick

... If at first you don't succeed, destroy all evidence that you tried.
--- AmberEdit/linux 0.9.0
* Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (1:154/10)

Hello Nick!


You are using a very old and unsupported version.

The one I use under Linux is v3.5.1 dated March 2025.

and no I do not assume it is bug free.



Vincent


01 Oct 26 07:53, you wrote to all:

Hey All!

If someone running the latest makenl can verify my findings, I would appreciate it:

https://github.com/zoomosis/makenl/issues/7

Steps to reproduce:

1) Purposely cause an error in one of your segments
2) Copy it to /received (or the "new" process directory) and/or keep a
copy of it in the master directory (ie. try both). 3) Run "makenl
<control file> -t" for "test mode". 4) Don't forget to revert any
changes back to normal after testing.

In my test cases, no errors were found at all using the "test" mode (I
had multiple errors that were there for months, and I don't paste my
logs for my 'othernet' like I do for Fidonet, so it went unnoticed).
It wasn't until processing manually where I noticed the problems,
after being notified that something was wrong.

Surprisingly, it didn't take long for chatgpt to indicate `"-t" sets mustbenew = 1, so openlist() doesn't even search UpdateDir or
MasterDir.`

I seem to have an easy fix in procfile.c (line 99), tested during this previous weekly run that nothing else was affected, and test mode now
works as expected:

```
- if (ShouldProcess == 0 && MergeOutFILE == 0) /* Process only
+ if (ShouldProcess == 0 && !JustTest && MergeOutFILE == 0) /* Process
only
new
files */
mustbenew = 1;Else
mustbenew = 0;
```

Regards,
Nick

... Sarcasm, because beating people up is illegal.

--- Mageia Linux v10 X64/Mbse v1.1.7.2/GoldED+/LNX 1.1.5-b20260905
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1)

Hi Nick,

On 2026-10-01 08:35:00, you wrote to me:

For the AmigaNet nodelist I found out a long time ago the test mode
is useless. For "testing" I just generate the nodelist for real (but
don't hatch it of course)...

Did you ever report it?

No, I didn't realise it could be a bug. Just thought I didn't really understood the test feature or what it was supposed to do. And I found a sollution by not using it, so there was no need to put more time into it. ;-)

Did you try my fix?

No. (Not yet)

Bye, Wilfred.

--- FMail-lnx64 2.3.4.1-B20260520
* Origin: FMail development HQ (2:280/464)

Hey Vincent!

On Thu, Oct 01 2026 14:34:00 +0100, you wrote:

You are using a very old and unsupported version.

Are you even paying attention?

The one I use under Linux is v3.5.1 dated March 2025.

I'm using the exact same one. That's why I said "the latest makenl" and gave the link to the source.

and no I do not assume it is bug free.

Thanks for your input.

Regards,
Nick

... Be kind to your kids, they'll be choosing your nursing home.
--- AmberEdit/linux 0.9.0
* Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (1:154/10)

Hey Wilfred!

On Thu, Oct 01 2026 16:02:16 +0200, you wrote:

No, I didn't realise it could be a bug. Just thought I didn't really understood the test feature or what it was supposed to do. And I found a sollution by not using it, so there was no need to put more time into it. ;-)

I guess my assumption was always that it should do exactly what "-p" (process mode) does, except don't hatch out new files.

Regards,
Nick

... Sarcasm, because beating people up is illegal.
--- AmberEdit/linux 0.9.0
* Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (1:154/10)

Hello Nick!

01 Oct 26 11:23, you wrote to Wilfred van Velzen:

No, I didn't realise it could be a bug. Just thought I didn't really
understood the test feature or what it was supposed to do. And I found
a sollution by not using it, so there was no need to put more time
into it. ;-)

I guess my assumption was always that it should do exactly what "-p" (process mode) does, except don't hatch out new files.

I use -t when I create a Region or Zone file.

# Test update files and move to update directory
${MAKENL} -t etc/zone2.ctl
err=$?
echo "Result code for Distrib = ${err}"
if [ "${err}" -lt "5" ]
then
# Assemble Zonelist
${MAKENL} etc/zone2.ctl
err=$?
echo "Result code for Distrib = ${err}"
if [ "${err}" -lt "2" ]
then
# Create distribution list
fi
fi

With -t Net/Region updates are moved from de inbound directory to the update
directory. When there sre errors in de segments, a error message is generate
for the C who submitted the file. The return code can be used to decide what
is done next. If I remember well -t return codes have an offset to the
return codes of in production. In -t mode no nodelists are created.

After production the return code shoud be less than 2

In the way you use makenl -t may have no visible results, but the test
mode does have a function when you import segments from others.

Do not remove it.

Kees

--- GoldED+/LNX 1.1.5--b20180707
* Origin: As for me, all I know is that, I know nothing. (2:280/5003.4)

Hey Kees!

On Thu, Oct 01 2026 20:28:58 +0200, you wrote:

After production the return code shoud be less than 2

In the way you use makenl -t may have no visible results, but the test
mode does have a function when you import segments from others.

Do not remove it.

When running from the command line, I wasn't getting any visible results. The patch I applied seems to have fixed that.

I don't plan on removing anything. Instead, I'm trying to /fix/ the issue I was having.

Regards,
Nick

... Politicians and diapers should be changed regularly for the same reasons. --- AmberEdit/linux 0.9.0
* Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (1:154/10)

Hello Nick!

01 Oct 26 13:48, you wrote to me:

When running from the command line, I wasn't getting any visible results. The patch I applied seems to have fixed that.

Did you set "loglevel x" in the controlfile? I use "1".

Kees

--- GoldED+/LNX 1.1.5--b20180707
* Origin: As for me, all I know is that, I know nothing. (2:280/5003.4)

Hey Kees!

On Thu, Oct 01 2026 20:59:54 +0200, you wrote:

When running from the command line, I wasn't getting any visible
results. The patch I applied seems to have fixed that.

Did you set "loglevel x" in the controlfile? I use "1".

Yes. I'm also using "loglevel 1".

* Keep in mind I've kept one timestamp from the original snippets on the very first line and removed the rest, and got rid of a couple extra spaces to format these snippets to fit in an 80 character terminal.

When I ran a test with an error in "agn1.txt" in the 'master' directory (I completely removed one 'sysop_name' field of one entry), the logs showed this:

- 25-Sep-2026 18:35:31 makenl[1319142]
MakeNL 3.5.1 (Linux) compiled with GNU C on Mar 8 2024 06:29:24
MakeNL started
Cmdline: ./makenl "agoranet.ctl" "-T"
Using 'agoranet.ctl' in '/home/fido/makenl'
Begin processing 'agoranet' -- 18:35, Friday, September 25, 2026
Processing Network 1 -- file '/home/fido/makenl/agoranet/agn1.txt' Processing Network 10 -- file '/home/fido/makenl/agoranet/agn10.261' Processing Network 2 -- file '/home/fido/makenl/agoranet/agn2.txt' Processing Network 20 -- file '/home/fido/makenl/agoranet/agn20.261' Processing Network 3 -- file '/home/fido/makenl/agoranet/agn3.txt' Processing Network 30 -- file '/home/fido/makenl/agoranet/agn30.261'
CRC = 00000
MakeNL finished (rc=3)

Then, I copied that segment to the 'update' directory:

- 25-Sep-2026 18:37:33 makenl[1319347]
MakeNL 3.5.1 (Linux) compiled with GNU C on Mar 8 2024 06:29:24
MakeNL started
Cmdline: ./makenl "agoranet.ctl" "-T"
Using 'agoranet.ctl' in '/home/fido/makenl'
Begin processing 'agoranet' -- 18:37, Friday, September 25, 2026
Processing Network 1 -- file '/home/fido/makenl/agoranet/received/agn1.txt' Processing Network 10 -- file '/home/fido/makenl/agoranet/agn10.261' Processing Network 2 -- file '/home/fido/makenl/agoranet/agn2.txt'
Processing Network 20 -- file '/home/fido/makenl/agoranet/agn20.261' Processing Network 3 -- file '/home/fido/makenl/agoranet/agn3.txt'
Processing Network 30 -- file '/home/fido/makenl/agoranet/agn30.261'
CRC = 00000
MakeNL finished (rc=3)

Then, after I applied the minor change to procfile.c, it finally caught the error:

- 25-Sep-2026 18:40:21 makenl[1319641]
MakeNL 3.5.2 (Linux) compiled with GNU C on Sep 25 2026 18:39:34
MakeNL started
Cmdline: ./makenl "agoranet.ctl" "-T"
makenl[1319641] Using 'agoranet.ctl' in '/home/fido/makenl'
Begin processing 'agoranet' -- 18:40, Friday, September 25, 2026
Processing Network 1 -- file '/home/fido/makenl/agoranet/received/agn1.txt' ,100,The_Pharcyde_HUB,Pewaukee_WI,-Unpublished-,300,CM,INA:binkp.pharcyde.org,IBN
agn1.txt -- Invalid baud rate -- 'CM'
Processing Network 10 -- file '/home/fido/makenl/agoranet/agn10.261' Processing Network 2 -- file '/home/fido/makenl/agoranet/agn2.txt'
Processing Network 20 -- file '/home/fido/makenl/agoranet/agn20.261' Processing Network 3 -- file '/home/fido/makenl/agoranet/agn3.txt'
Processing Network 30 -- file '/home/fido/makenl/agoranet/agn30.261'
CRC = 00000
MakeNL finished (rc=4)

"-p" or 'process mode' is unchanged/unaffected, as far as I can tell.

Regards,
Nick

... I'm sarcastic, what's your superpower?
--- AmberEdit/linux 0.9.0
* Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (1:154/10)

Hello Nick!

01 Oct 26 17:01, you wrote to me:

* Keep in mind I've kept one timestamp from the original snippets on the very first line and removed the rest, and got rid of a couple extra spaces to format these snippets to fit in an 80 character terminal.

When I ran a test with an error in "agn1.txt" in the 'master' directory (I completely removed one 'sysop_name' field of one entry), the logs showed this:

- 25-Sep-2026 18:35:31 makenl[1319142]
MakeNL 3.5.1 (Linux) compiled with GNU C on Mar 8 2024 06:29:24
MakeNL started
Cmdline: ./makenl "agoranet.ctl" "-T"

I am not shure if it like the capital T. It to late to try now 00:30 AM

Using 'agoranet.ctl' in '/home/fido/makenl'
Begin processing 'agoranet' -- 18:35, Friday, September 25, 2026 Processing Network 1 -- file '/home/fido/makenl/agoranet/agn1.txt' Processing Network 10 -- file '/home/fido/makenl/agoranet/agn10.261' Processing Network 2 -- file '/home/fido/makenl/agoranet/agn2.txt' Processing Network 20 -- file '/home/fido/makenl/agoranet/agn20.261' Processing Network 3 -- file '/home/fido/makenl/agoranet/agn3.txt' Processing Network 30 -- file '/home/fido/makenl/agoranet/agn30.261' CRC = 00000
MakeNL finished (rc=3)

It gives a return code 3, that indicates an error

Then, I copied that segment to the 'update' directory:

- 25-Sep-2026 18:37:33 makenl[1319347]
MakeNL 3.5.1 (Linux) compiled with GNU C on Mar 8 2024 06:29:24
MakeNL started
Cmdline: ./makenl "agoranet.ctl" "-T"
Using 'agoranet.ctl' in '/home/fido/makenl'
Begin processing 'agoranet' -- 18:37, Friday, September 25, 2026 Processing Network 1 -- file '/home/fido/makenl/agoranet/received/agn1.txt' Processing Network 10 -- file '/home/fido/makenl/agoranet/agn10.261' Processing Network 2 -- file '/home/fido/makenl/agoranet/agn2.txt' Processing Network 20 -- file '/home/fido/makenl/agoranet/agn20.261' Processing Network 3 -- file '/home/fido/makenl/agoranet/agn3.txt' Processing Network 30 -- file '/home/fido/makenl/agoranet/agn30.261' CRC = 00000 MakeNL finished (rc=3)

You can see no nodelist is produces as de CRC = 00000
the rc does not look right to me as I beleice 4 is the lowest for -t

Then, after I applied the minor change to procfile.c, it finally
caught
the
error:

- 25-Sep-2026 18:40:21 makenl[1319641]
MakeNL 3.5.2 (Linux) compiled with GNU C on Sep 25 2026 18:39:34
MakeNL started
Cmdline: ./makenl "agoranet.ctl" "-T"
makenl[1319641] Using 'agoranet.ctl' in '/home/fido/makenl'
Begin processing 'agoranet' -- 18:40, Friday, September 25, 2026 Processing Network 1 -- file '/home/fido/makenl/agoranet/received/agn1.txt' ,100,The_Pharcyde_HUB,Pewauk ee_WI,-Unpublished-,300,CM,INA:binkp.pharcyde.org,IBN agn1.txt -- Invalid baud rate -- 'CM' Processing Network 10 -- file '/home/fido/makenl/agoranet/agn10.261' Processing Network 2 -- file '/home/fido/makenl/agoranet/agn2.txt' Processing Network 20 -- file '/home/fido/makenl/agoranet/agn20.261' Processing Network 3 -- file '/home/fido/makenl/agoranet/agn3.txt' Processing Network 30 -- file '/home/fido/makenl/agoranet/agn30.261' CRC = 00000 MakeNL finished (rc=4)

Here the rc = 4 is different, the logfiles only mention the files
used.

"-p" or 'process mode' is unchanged/unaffected, as far as I can tell.

As for where incoming en tested files should go is in de config file.

Your new files goes into incoming, -t moves it to update and there is

I am getting a bit dense, I will be more coherent in daytime.

Kees

--- GoldED+/LNX 1.1.5--b20180707
* Origin: As for me, all I know is that, I know nothing. (2:280/5003.4)

Hello Nick!

01 Oct 26 11:21, you wrote to me:

Hey Vincent!

On Thu, Oct 01 2026 14:34:00 +0100, you wrote:

You are using a very old and unsupported version.

Are you even paying attention?

YES.

The one I use under Linux is v3.5.1 dated March 2025.

I'm using the exact same one. That's why I said "the latest makenl"
and gave the link to the source.

No, you asked if any one was and did not specify the version you are, using.

and no I do not assume it is bug free.

Thanks for your input.

You are welcome.


Vincent


--- Mageia Linux v10 X64/Mbse v1.1.7.2/GoldED+/LNX 1.1.5-b20260905
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1)

Hey Kees!

On Fri, Oct 02 2026 00:36:22 +0200, you wrote:

Cmdline: ./makenl "agoranet.ctl" "-T"

I am not shure if it like the capital T. It to late to try now 00:30 AM

This is only in the logfile. I actually ran it with a lowercase 't'. You can run it either way, though.

MakeNL finished (rc=3)

It gives a return code 3, that indicates an error

That's not enough for me, then (also, I didn't know that). I wanted the error actually written out. I went years with errors in my segment because test mode wasn't actually telling me the line the error was on, whereas process mode was (and I wasn't looking at it, because I had assumed there were no errors because test mode wasn't telling me clear enough).

Then, I copied that segment to the 'update' directory:

You can see no nodelist is produces as de CRC = 00000
the rc does not look right to me as I beleice 4 is the lowest for -t

Correct, no nodelist is produced because I ran it in test mode. I'm not sure what the rc is about, but I want to catch the actual error, as shown in the last log snippet.

Then, after I applied the minor change to procfile.c, it finally caught
the error:

Here the rc = 4 is different, the logfiles only mention the files
used.

I suppose I was unsure as to anything 'rc' meant. Test mode shouldn't show it processing a segment without the line that has an error (like process mode does), IMO.

As for where incoming en tested files should go is in de config file.

Yes, I know. They are set accordingly, and the log files showed the difference between being in the 'master' and 'update' directories.

Your new files goes into incoming, -t moves it to update and there is

When edited manually by myself in the 'master' directory, '-t' doesn't move it to the 'update' directory. I do that manually once I know there are no errors. Then '-p' process mode moves any new segments found in the 'update' directory from to the 'master' directory. If new segments are not found in the 'update' directory, they are processed from the 'master' directory.

I am getting a bit dense, I will be more coherent in daytime.

No problem.

Regards,
Nick

... If at first you don't succeed, destroy all evidence that you tried.
--- AmberEdit/linux 0.9.0
* Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (1:154/10)

Hey Vincent!

On Fri, Oct 02 2026 00:23:38 +0100, you wrote:

No, you asked if any one was and did not specify the version you are, using.

Why would I create an issue on github (and link to it) where the latest sources reside if I wasn't running the latest sources? I didn't want a response from anyone using an older version, which is why I asked for people that were on the latest sources (as I am).

Regards,
Nick

... He who laughs last, thinks slowest.
--- AmberEdit/linux 0.9.0
* Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (1:154/10)

Hello Nick!

01 Oct 26 18:50, you wrote to me:

Hey Vincent!

On Fri, Oct 02 2026 00:23:38 +0100, you wrote:

No, you asked if any one was and did not specify the version you
are, using.

Why would I create an issue on github (and link to it) where the
latest sources reside if I wasn't running the latest sources? I didn't
want a response from anyone using an older version, which is why I
asked for people that were on the latest sources (as I am).

You are again "assuming".

As a programmer I try to avoid doing that - for obvious reasons.
It assumes all readers KNOW what the latest version is and in fido that is one assumption
too many.


Vincent


--- Mageia Linux v10 X64/Mbse v1.1.7.2/GoldED+/LNX 1.1.5-b20260905
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1)

Hello Nick!

01 Oct 26 18:47, you wrote to me:

This is only in the logfile. I actually ran it with a lowercase 't'. You can run it either way, though.

O.K.

MakeNL finished (rc=3)

It gives a return code 3, that indicates an error

That's not enough for me, then (also, I didn't know that).

It's in the docs.

I wanted the
error actually written out. I went years with errors in my segment
because
test mode wasn't actually telling me the line the error was on, whereas process mode was (and I wasn't looking at it, because I had assumed there were no errors because test mode wasn't telling me clear enough).

As far as I know errors are reported to the senders of the update.
makenl is designed to run unsupervised in batch mode.

Here the rc = 4 is different, the logfiles only mention the files
used.

I suppose I was unsure as to anything 'rc' meant.

the exit code of a closing program.

I am not aware of the specifity you want in the error reporting of makenl.
I cannot help you there.

Kees

--- GoldED+/LNX 1.1.5--b20180707
* Origin: As for me, all I know is that, I know nothing. (2:280/5003.4)

Hey Vincent!

On Fri, Oct 02 2026 14:33:24 +0100, you wrote:

You are again "assuming".

*Facepalm*

Regards,
Nick

... Sarcasm, because beating people up is illegal.
--- AmberEdit/linux 0.9.0
* Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (1:154/10)

Hey Kees!

On Fri, Oct 02 2026 22:05:58 +0200, you wrote:

I am not aware of the specifity you want in the error reporting of
makenl.

I cannot help you there.

I wasn't asking for your help. Instead, I was asking for verification that others using the latest sources weren't seeing what the error actually was.

I made it do what I wanted it to do (It now reports /what/ the error is while in test mode (-t) - much like process mode does, not just that there /is/ an error specified with an exit code), and announcing the patch here if anyone wants to use it.

Regards,
Nick

... He who laughs last, thinks slowest.
--- AmberEdit/linux 0.9.0
* Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (1:154/10)

Hello Nick!

02 Oct 26 18:45, you wrote to me:

I wasn't asking for your help. Instead, I was asking for verification that others using the latest sources weren't seeing what the error actually was.

O.K. I misunderstood that.

I made it do what I wanted it to do (It now reports /what/ the error
is
while in test mode (-t) - much like process mode does, not just that there /is/ an error specified with an exit code), and announcing the patch here if anyone wants to use it.

Send the Patch to Andrew Leary, I think he still maintains the distributed
sources.

Maybe your patch should have its own parameter to activate, so it will not
change the the output currently produced by -t.

Kees

--- GoldED+/LNX 1.1.5--b20180707
* Origin: As for me, all I know is that, I know nothing. (2:280/5003.4)

Hey Kees!

On Sat, Oct 03 2026 15:25:42 +0200, you wrote:

Send the Patch to Andrew Leary, I think he still maintains the
distributed sources.

I did that before even posting about it here. ;)

Maybe your patch should have its own parameter to activate, so it will
not change the the output currently produced by -t.

Maybe. That's up to the maintainer, I suppose.

IMO, I don't really see enough reason to make a new parameter, though, unless it would be an option or extension to '-t' for 'verbose', or something in those lines. It basically does the exact same thing it did, just outputs more information in test mode. Rather than "there is an error..." the patch makes it "there is an error, and this is what it is ..."

Just as well, it doesn't need to be changed at all, really. If that was the original way it was intended, so be it. I didn't understand why it wouldn't tell you what the actual error was, so I made it do so.

If people already have their own workarounds in place (ie. running it in process mode instead of even using test mode, or using a script of some sort to verify what the error actually is), then let it be. ;)

Regards,
Nick

... Be kind to your kids, they'll be choosing your nursing home.
--- AmberEdit/linux 0.9.0
* Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (1:154/10)