Hello Code warriors!

For some time there has heen a nodelist line in the segment maintained by
Hoe Delahaye, with the following snippet: ....., IBN:.....

I have informed Joe of the fact, but he is visiting relatives in Z2 now,
so i may be a few weeks before he can act.

I have always assumed, that there should be no spaces in nodelist entries,
but makenl_ng makes no objections.

Parsers that extract data from the nodelist may also be developed, with
that assumption in mind and possibly not recognize this flag.

Should makenl_ng flag spaces in a node line as errors?
Should makenl_ng remove these spaces, probably a nono, as makenl should not
apply automatic editing of nodelist lines..

Kees

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

Kees,

I have always assumed, that there should be no spaces in nodelist
entries, but makenl_ng makes no objections.

ERRFLAGS does. It will be recognised as an error.

\%/@rd

--- D'Bridge 3.99
* Origin: Many Glacier / Protect - Preserve - Conserve (2:292/854)

Hello Ward!

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

Kees,

I have always assumed, that there should be no spaces in nodelist
entries, but makenl_ng makes no objections.

ERRFLAGS does. It will be recognised as an error.

That is nice, sadly the other zones do not use ERRFLAGS, so I think it
should be added to makenl as an error condition.

I have changed my parsers that handle the nodelist, to remove spaces as their
first action.

Kees

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

Hello Kees,

On Wednesday October 01 2014 16:22, you wrote to Code warriors:

Should makenl_ng flag spaces in a node line as errors?

Definitely! According to FTS-5000 it IS an error.

5.3. Data lines
----------------

A nodelist data line contains no less than seven (7) variable length
fields separated by commas (2Ch), defined below. Each data line is
a record/entry for an individual Fidonet node.

Printable ASCII characters except for commas and spaces are allowed
in all string fields unless specified otherwise. Underscores (5Fh)
are always used in place of spaces (20h).

Should makenl_ng remove these spaces,

Or replace them with an underscore?

probably a nono, as makenl should not apply automatic editing of
nodelist lines..

Replacing with an underscore will most likely give the desired result in the name fields. removing spaces will most likely result in line that parses. Or it
may produce another error.

Perhaps it is better to let a human judge. But it definitely should be flagged as an error!


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20130111
* Origin: http://www.vlist.eu (2:280/5555)

Hello Michiel!

01 Oct 14 18:01, you wrote to me:

Should makenl_ng flag spaces in a node line as errors?

MvdV> Definitely! According to FTS-5000 it IS an error.

MvdV> in all string fields unless specified otherwise. Underscores (5Fh)
MvdV> are always used in place of spaces (20h).

Should makenl_ng remove these spaces,

MvdV> Or replace them with an underscore?

That would be just as useless for a flag field as the space. The Flag would
now certainly be ignored.

probably a nono, as makenl should not apply automatic editing of
nodelist lines..

MvdV> Replacing with an underscore will most likely give the desired result in
MvdV> the name fields. removing spaces will most likely result in line that
MvdV> parses. Or it may produce another error.

MvdV> Perhaps it is better to let a human judge.

probaly.

MvdV> But it definitely should be flagged as an error!

right.

Kees

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

Kees,

ERRFLAGS does. It will be recognised as an error.

That is nice, sadly the other zones do not use ERRFLAGS, so I think it should be added to makenl as an error condition.

What you're actually saying is that 20% of the nodelist doesn't use it. Right?

Plus, a space in a nodelist-entry by definition is an error.

\%/@rd

--- D'Bridge 3.99
* Origin: Many Glacier / Protect - Preserve - Conserve (2:292/854)

On Thu, 02 Oct 2014, Ward Dossche wrote to Kees van Eeten:

ERRFLAGS does. It will be recognised as an error.

That is nice, sadly the other zones do not use ERRFLAGS, so I think it should be added to makenl as an error condition.

What you're actually saying is that 20% of the nodelist doesn't use
it. Right?

your math is broken... 75% don't use ERRFLAGS... only one zone of four does...

Plus, a space in a nodelist-entry by definition is an error.

definitely... the first question is what tool does joe use for his nodelist processing... a secondary question is what did the original ben baker tool do in a case like this?

)\/(ark


* Origin: (1:3634/12)

What you're actually saying is that 20% of the nodelist doesn't use ml>WD> it. Right?

your math is broken... 75% don't use ERRFLAGS... only one zone of four does...

75% (rough guess) of the nodelist's entries are processed by ERRFLAGS.

BTW, there's one zone with a single active node. And "yes", we've had that discussion already twice before ...

Plus, a space in a nodelist-entry by definition is an error.

definitely... the first question is what tool does joe use for his
nodelist processing... a secondary question is what did the original ben baker tool do in a case like this?

I think in the past there have been blanks before, and there have been more tools than just Ben Baker's original.

Joe's system is OS2 ... I think, not certain.

\%/@rd

--- D'Bridge 3.99
* Origin: Many Glacier / Protect - Preserve - Conserve (2:292/854)

Hello mark,

On Thursday October 02 2014 11:30, you wrote to Ward Dossche:

What you're actually saying is that 20% of the nodelist doesn't
use it. Right?

your math is broken... 75% don't use ERRFLAGS... only one zone of four does...

Oh c'mon... you can't be serious in your implication that the one man zone that
does not use it, carries the same weight in the 2000+ man zone that does?

Plus, a space in a nodelist-entry by definition is an error.

definitely... the first question is what tool does joe use for his nodelist processing... a secondary question is what did the original
ben baker tool do in a case like this?

Why? Ben Baker's original tool has been replaced by something that fits today's
needs. If there is a problem with it, we should look at what we want now. If you have a problem with your car, you don't go to the museum to check how a T Ford behaves under today's conditions do you?


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20130111
* Origin: http://www.vlist.eu (2:280/5555)

Joe's system is OS2 ... I think, not certain.

No, Joe is running win32:

>SBBSecho 2.27-Win32

--- BBBS/Li6 v4.10 Dada-1
* Origin: Prism bbs (1:261/38)

Hello Michiel!

Wednesday October 01 2014 18:01, Michiel van der Vlist wrote to Kees van Eeten:

Should makenl_ng flag spaces in a node line as errors?

MvdV> Definitely! According to FTS-5000 it IS an error.

Agreed.

Should makenl_ng remove these spaces,

MvdV> Or replace them with an underscore?

probably a nono, as makenl should not apply automatic editing of
nodelist lines..

MvdV> Replacing with an underscore will most likely give the desired result
MvdV> in the name fields. removing spaces will most likely result in line
MvdV> that parses. Or it may produce another error.

MvdV> Perhaps it is better to let a human judge. But it definitely should be
MvdV> flagged as an error!

I just dug through the code. Currently leading or trailing spaces in the first
7 fields (keyword, number, name, location, sysop, telephone, baudrate) of a nodelist line will be removed. The issue here is an incorrect entry with a space embedded in the flags field. MakeNL has never done error checking on the
flags, which is why ERRFLAGS was developed in the first place. I suppose I could add basic error checking of the flags (probably limited to flagging illegal characters such as spaces.) Anything more extensive would probably involve rewriting ERRFLAGS in C and merging it with MakeNL. That is a project that would require extensive amounts of time to code, test, and debug. Given that some of the current ZCs refuse to use ERRFLAGS, I don't imagine they would
want to have the equivalent added to MakeNL.

Regards,

Andrew

---
* Origin: Bits & Bytes BBS * V.Everything! * 860/535-4284 (1:320/119)

Hello Michiel!

Wednesday October 01 2014 18:01, Michiel van der Vlist wrote to Kees van Eeten

Should makenl_ng flag spaces in a node line as errors?

Definitely! According to FTS-5000 it IS an error.

Agreed.

Should makenl_ng remove these spaces,

Or replace them with an underscore?

probably a nono, as makenl should not apply automatic editing of
nodelist lines..

Replacing with an underscore will most likely give the desired result
in the name fields. removing spaces will most likely result in line
that parses. Or it may produce another error.

Perhaps it is better to let a human judge. But it definitely should be
flagged as an error!

I just dug through the code. Currently leading or trailing spaces in the firs
7 fields (keyword, number, name, location, sysop, telephone, baudrate) of a nodelist line will be removed. The issue here is an incorrect entry with a
space embedded in the flags field. MakeNL has never done error checking on th
flags, which is why ERRFLAGS was developed in the first place. I suppose I could add basic error checking of the flags (probably limited to flagging illegal characters such as spaces.) Anything more extensive would probably
involve rewriting ERRFLAGS in C and merging it with MakeNL. That is a project
that would require extensive amounts of time to code, test, and debug. Given
that some of the current ZCs refuse to use ERRFLAGS, I don't imagine they woul
want to have the equivalent added to MakeNL.

Good points Andrew. I would not like it merged with makenl.

Take care,
Janis

--- BBBS/Li6 v4.10 Dada-1
* Origin: Prism bbs (1:261/38)

Hello mark!

02 Oct 14 11:30, you wrote to Ward Dossche:

What you're actually saying is that 20% of the nodelist doesn't use
it. Right?

your math is broken... 75% don't use ERRFLAGS... only one zone of four does...

I think we are talking about the number of node lines processed by ERRFLAGS.

The Z2 Dailylist of day 275 had 2995 nodelines. Of these 2210 were from
Z2. My math tells me that is about 73.79% and you may argue about the 2nd
decimal. For comparison 18.56% of the lines are from Z1 and 3.34% from Z3.
Amazingly Z4 contributes 4.30% of the nodelist entries, to list a zone with
very few active sysops.

This is about lines processed by ERRFLAG, very different numbers will be
obtained if we look for individual sysop names, but I will leave that for
another day.

Kees

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

Hello Andrew!

02 Oct 14 14:10, you wrote to Michiel van der Vlist:

I just dug through the code. Currently leading or trailing spaces in the first 7 fields (keyword, number, name, location, sysop, telephone, baudrate) of a nodelist line will be removed. The issue here is an incorrect entry with a space embedded in the flags field. MakeNL has never done error checking on the flags, which is why ERRFLAGS was developed in the first place. I suppose I could add basic error checking of the flags (probably limited to flagging illegal characters such as spaces.) Anything more extensive would probably involve rewriting ERRFLAGS in C and merging it with MakeNL. That is a project that would require extensive amounts of time to code, test, and debug. Given that some of the current ZCs refuse to use ERRFLAGS, I don't imagine they would want to have the equivalent added to MakeNL.

I can agree with your agument. Considering the frequency of this error
ocurring, we should probably leave it as it is. And those who care can use
ERRFLAGS. Personally I think it would be an asset to makenl. The program
performs a basic set of errors, that should not occur and have to be repaired
anyway. All other checks are added via the configuration file.

As for the unwillingness to use ERRFLAGS, I can only guess.
I can think of some reasons. The main being that at first sight the
configuration file, was tailored to the likes of one ZC and that configuration
was more strickt than what other ZC allowed in their segments. Running the
program produced many error messages on Zone accepted notations.

If ERRFLAGS had been introduced with a very forgiving configuration file, it would probably have had a better chance.

As a last the ERRFLAGS probanly suffered from the not invented here syndrome,
or the initiative to its development was taken by the wrong person.
I am not going into that argument.

Kees

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

Hello Janis!

02 Oct 14 17:44, you wrote to Andrew Leary:

merging it with MakeNL. That is a project that would require extensive
amounts of time to code, test, and debug. Given that some of the current
ZCs refuse to use ERRFLAGS, I don't imagine they woul want to have the
equivalent added to MakeNL.

Good points Andrew. I would not like it merged with makenl.

In opposition of what I wrote in my previous message, I have nagging feeling,
that I cannot put into words, that it is better to keep it separate.
And as a *nix user I still prefer filter type inplementations over monoliths.

Kees

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

Andrew,

I don't imagine they
would want to have the equivalent added to MakeNL.

I concur.

Now it's an opt-in/opt-out thing that keeps both sides happy although my Z1-brethren and sistern are opposed to it merely because I'm in favor.

\%/@rd

--- D'Bridge 3.99
* Origin: Many Glacier / Protect - Preserve - Conserve (2:292/854)

Kees,

This is about lines processed by ERRFLAG, very different numbers will be obtained if we look for individual sysop names, but I will leave that
for another day.

That has been my thing for years:

Z1 307 ... 15,96%
Z2 1589 ... 82,89%
Z3 19 ... 0,99%
Z4 9 ... 0,47%
----
1924

These are the numbers of individually listed sysops, give or take a few.

Interesting to note is there is 1 active system in Z4 that can be reached, the ZC's system. Unfortunately the young man does not understand what he is doing:

* he still publishes ZMH for zones which have been gone for years
* he still publishes zonegates while none of the other zones have any
* One of his nodes is living in Los Angeles as a student and the other is
relocating in the same capacity to the UK for a long period. So rather
than putting them down and remove them, he decided to put them on hold
for longer than a year in case they return. Now we all know how Ioram
Sette could not be dialed for years, so whether or not he returns won't
make much of a difference.

When making the above count, I acknowledge there must be a lot of dead would in
Z1, Z2 and Z4. Z3 is pretty OK I think. It means the number of actually active and involved is dramatically lower than these numbers.

Where are the days there were 36.000 of us plus hundreds of thousands of point systems plus ditto BBS-users...

Take care,

\%/@rd

--- D'Bridge 3.99
* Origin: Many Glacier / Protect - Preserve - Conserve (2:292/854)

Re: feature request
By: mark lewis to Ward Dossche on Thu Oct 02 2014 11:30:11

definitely... the first question is what tool does joe use for his nodelist processing... a secondary question is what did the original ben baker tool do in a case like this?

The ansert tyo the first question is MakeNL. Ome of the latests versions. Cant tell you from here what version exactly. I dont know the answer to the second question <G>
--- SBBSecho 2.27-Win32
* Origin: The Lions Den BBS, Trenton, On, CDN (1:249/303)

Re: Re: feature request
By: Ward Dossche to mark lewis on Thu Oct 02 2014 19:03:41

Joe's system is OS2 ... I think, not certain.

Windows Vista :)
--- SBBSecho 2.27-Win32
* Origin: The Lions Den BBS, Trenton, On, CDN (1:249/303)

On Sat, 04 Oct 2014, Michiel van der Vlist wrote to Andrew Leary:

The issue here is an incorrect entry with a space embedded in the
flags field. MakeNL has never done error checking on the flags,

MvdV> An embedded space is a more general error than an unauthorized
MvdV> flag.

my thoughts exactly... in my mind, the first thing to check in a line would be if any spaces exist internally to the line at all... if they do, then report an
error... then decide to either remove the spaces and continue on or abort processing of said line and list an error for the line in the output file... initially, my thought would be to list the error, strip the spaces and continue
on but this might be better as a config option...

)\/(ark


* Origin: (1:3634/12)

On Sat, 04 Oct 2014, Michiel van der Vlist wrote to Janis Kracht:

and debug. Given that some of the current ZCs refuse to use
ERRFLAGS, I don't imagine they woul want to have the equivalent
added to MakeNL.

Good points Andrew. I would not like it merged with makenl.

MvdV> Errflags can easely be configured to do "nothing". And so by
MvdV> implication would an an errflags merged with Makenl.

while i applaude ERRFLAGS operations, i do not like it because it forces approved flags... even in "do nothing" mode the operator of said tool has to deal with the so-called "errors"... U flags, in particular, were never supposed
to be "approved" and then there's the possibility of experimental flags which generally start as U flags and then may be moved to non-U flags... this then seems to become a political problem because some *C may not approve of said flag while others might... thus we end up mixing politics with technical aspects... this is not a GoodThing<tm> and it wasn't when ERRFLAGS was introduced even though it gave the possibility of conformance it was and has been used as a political tool instead of a technical tool...

)\/(ark


* Origin: (1:3634/12)

Mark,

... and it wasn't when ERRFLAGS was introduced even though it gave the possibility of conformance it was and has been used as a political tool instead of a technical tool...

ERRFLAGS is nothing else than a preprocessor for MAKENL ... remember the days when there was only 1 MAKENL, its author vanished and no source-code to work with?

Besides, when I took over as Z2C on Oct.4th 1994 (20 yrs ago ... arghhh) there was another preprocessor that was handed to me developped by one Ron Dwight. Actually, I agreed with the principle of conforming, but then when I wanted some changes applied Ron Dwight (ex-ZC) refused to apply them and didn't share the source-code). Hence: ERRFLAGS.

Do not misinterprete my nagging of certain powers that be with the usefulness of the tool.

Plus, the comments about it come exclusively from Z1 ... with less than a handful in Z2 for questionable reasons. There is no grand opposition here.

And frankly, seeing the numbers and the decline (plus the lack of content) I wonder if it really is an issue worthy of discussion. I'd rather enjoy the time
that remains for us in Fido, visit a few friends, have a meal, have a beer, chat a bit than get worked-up over silly things.

37 on the ticker when I started in Fidonet, 63 now (64 soon) and i want to enjoy it for as long as there's something to enjoy.

Politics? Whomever wanted to try something and came-up with some flags to suit whatever purpose, was never rejected. I think.

Take care,

\%/@rd

--- D'Bridge 3.99
* Origin: Many Glacier / Protect - Preserve - Conserve (2:292/854)

Hello mark,

On Sunday October 05 2014 21:10, you wrote to me:

while i applaude ERRFLAGS operations, i do not like it because it
forces approved flags... even in "do nothing" mode the operator of
said tool has to deal with the so-called "errors"... U flags, in particular, were never supposed to be "approved" and then there's the possibility of experimental flags which generally start as U flags and then may be moved to non-U flags...

When citisizing something one should know what one is taling about. When I mentioned ERRFLAGS could easely be configured to do "nothing", I did not mean run it in check mode.
This configuration file will make it do "nothing".

BAUDDEFAULT 9600
BAUDRATE 300 1200 2400 4800 9600 14400 16800 19200 28800 33600
FLAGS *
USER *

this then seems to become a political problem because some *C may not approve of said flag while others might... thus we end up mixing
politics with technical aspects...

Once we had an IC and flags had to be IC approved...

this is not a GoodThing<tm> and it wasn't when ERRFLAGS was introduced even though it gave the possibility of conformance it was
and has been used as a political tool instead of a technical tool...

Your opinion.... It is not shared by the majority of the sysops in the zone where the nodelist is cleaned up by ERRFLAGS


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20130111
* Origin: http://www.vlist.eu (2:280/5555)

MvdV> BAUDRATE 300 1200 2400 4800 9600 14400 16800 19200 28800 33600

But then again, since many *Cs have used my patched version of the original MakeNL for ages, that field has kinda redundant for a decade and a half. I removed that check completely, since it serves absolutely no purpose. Never has, except possibly as penis enhancer for some people in need for that...

--- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125
* Origin: news://felten.yi.org (2:203/2)

Hello Björn,

On Monday October 06 2014 18:09, you wrote to me:

MvdV>> BAUDRATE 300 1200 2400 4800 9600 14400 16800 19200 28800 33600

But then again, since many *Cs have used my patched version of the original MakeNL for ages, that field has kinda redundant for a decade
and a half.

True, it does not serve a purpose any more. But for backward compatibility we can not just put anything there. Many nodelist processing sofware will barf if theer are jyst two adjacent commas. Or something that is not an integer. And as
it serves no purpose, it does not hurt to check for "funny" input and replace it with "9600" does it?

I removed that check completely, since it serves absolutely no
purpose. Never has, except possibly as penis enhancer
for some people in need for that...

The Baud rate field DID serve a purpose in the very early days when there were modems without buffers and RTS/CTS handshake. They required that the DCE/DTE speed was set to the same value as the line speed.


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20130111
* Origin: http://www.vlist.eu (2:280/5555)

Hello Michiel!

Saturday October 04 2014 00:16, Michiel van der Vlist wrote to Andrew Leary:

I just dug through the code. Currently leading or trailing
spaces in the first 7 fields (keyword, number, name, location,
sysop, telephone, baudrate) of a nodelist line will be removed.

MvdV> Leading and trailing spaces, but not spaces in the middle?

In the keyword field they should cause an invalid keyword error. In the number, telephone, and baudrate fields, they should cause an error because they
are not digits. I will have to look a little closer to see how the code reacts
to embedded spaces in the name, location, and sysop fields.

The issue here is an incorrect entry with a space embedded in the
flags field. MakeNL has never done error checking on the flags,

MvdV> An embedded space is a more general error than an unauthorized flag.

True.

which is why ERRFLAGS was developed in the first place. I
suppose I could add basic error checking of the flags (probably
limited to flagging illegal characters such as spaces.) Anything
more extensive would probably involve rewriting ERRFLAGS in C and
merging it with MakeNL. That is a project that would require
extensive amounts of time to code, test, and debug.

MvdV> It is doable. I have build errflags functionality in my pointlist
MvdV> assembler. It is open source...

I certainly agree that it can be done. However, for the reasons that have been
brought up here, it isn't worth the time and effort required. I may work on it
separately from MakeNL in the future.

Given that some of the current ZCs refuse to use ERRFLAGS, I
don't imagine they would want to have the equivalent added to
MakeNL.

MvdV> I agree.

MvdV> Perhaps just flag any space in a line it as a warning. Or maybe just
MvdV> forget about it. It is a rare occasion that may never happen again
MvdV> once Joe is back home and corrects it.

I will look into flagging any entry containing embedded spaces as an error.

MvdV> It does not seem to break anything or it would have been noticed
MvdV> before...

True.

Andrew

---
* Origin: Bits & Bytes BBS * V.Everything! * 860/535-4284 (1:320/119)