On 2019 May 01 19:08:30, you wrote to me:

 ml>> 1c. ignore it and do not write it to the output (aka skip)

 MK> That sounds like what I called stripping in the previous post.  Basically
 MK> it has the same effect if it isn't in the output.

yes and that's a problem that some coders don't seem to understand...

 ml>> a lot of code does #1 when it should do #2...

 MK> I am not convinced it "should" do either but perhaps in certain cases
there
 MK> could be characters that might do "harm" such as some ansi bbses do to
 MK> user's terminals.  I used to have to run reset after logging out of bbses
 MK> to get things back to normal after telnetting to them.

that's them or your terminal simply not resetting things properly... i see it,
too, when displaying ANSIs and have also seen it when displaying animated web
graphics when breaking out of them to return to the terminal...

 MK> This is what led me to where I am today as far as offline messaging is
[...]
 MK> Bottomline is there is way too much that goes awry when dealing with
 MK> differing codepages and stripping out codes will definetly cause harm
 MK> to messages.

agreed... remember, though, that much of fidonet was created by hobbiests...
that's not a bacd thing, though... just they don't always consider or even know
 "all the things"...

 ml>> that in nancy's case, she sees the characters after

 MK> Yes but Nancy's editor is perfect for testing since we both know for a
 MK> fact it does no harm, even to utf8 characters which she cannot
 MK> 'properly' render but she can see the 8 bit hex codes as they map out
 MK> to IBM437.  If anything is amiss it is obvious when she quotes
 MK> whatever is of concern back as is in the case of the "loses an i" bug.

true but that may be dependent on which BBS she is using for her replies at
that time... i don't know if she is using my offline capabilities here or
not... i do have another user that cycles uploading messages between three or
four BBSes... plus there's whatever path the messages may take from where they
upload their messages... this path used to be reliable and easily used to track
 down problematic systems but with "fidoweb" and going "against the grain" of
fidonet and not sending duplicates, there are numerous paths that may be
taken...

 ml>> keep on with the poking... it may result in some real good for the
 ml>> network one day

 MK> You too.  Your call on this particular issue was bang on.  I now bow
 MK> to the master.

i'm no master but thank you  :blush:

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it
wrong...
... If you don't like me tailgating, buy bumper stickers with bigger words.
---
 * Origin:  (1:3634/12.73)