When I look at the packet after it arrives on "A" - no change. sbbsecho tosses the packet fine. The message is in the same format still (inside the packet).
When I look at the message in "A" using msgbase.get_msg_body() - all the 0x0A have been stripped. So the message on "A" is not the same as the message on "B". Why would the 0x0A be stripped, and can I stop that?
Any chance you have "Strip outgoing line feeds" enabled in echocfg?
No - because the outgoing packet has the line feeds.
Another idea?
Hey DM,
I've set up a second SBBS system, while I test some messages going back and forth between it and my main SBBS. I'm playing with gpg signed messages (I'm working on something).
SBBS "A" is my main system, SBBS "B" is the test.
When I generate a message on "B", that gets posted into a sub using msgbase.save_msg(), sbbsexports it (BAU) sends it to "A".
When I look at the message in "B" using msgbase.get_msg_body() - I see the format of the message is as it was when I generated it.
When I look at the packet that sbbsecho exports from "B" to send to "A" - the message is "as is" it was when it went into the sub.
When I look at the packet after it arrives on "A" - no change. sbbsecho tosses the packet fine. The message is in the same format still (inside the packet).
When I look at the message in "A" using msgbase.get_msg_body() - all the 0x0A have been stripped. So the message on "A" is not the same as the message on "B". Why would the 0x0A be stripped, and can I stop that?
Because those are line-feeds and the FTSC specs say that line-feeds should be "ignored" (with no real definition of what "ignore" means).
Still, SBBSecho has an option to strip line-feeds and when not enabled, they should be preserved - at least when SBBSecho is in use. But other tossers could certainly strip them between systems. It's best
to not assume that all white-space characters are going to be preserved between FTN endpoints.
Re: Imported messages being modified
By: Digital Man to Alterego on Mon Oct 14 2019 11:56 pm
Because those are line-feeds and the FTSC specs say that line-feeds should be "ignored" (with no real definition of what "ignore" means).
Hmm... If that were true, it doesnt make sense.
The message body is changed,
and I would have thought that the message body not be changed between systems. (Especially in this case, when the two systems are the same software on the same OS).
Still, SBBSecho has an option to strip line-feeds and when not enabled, they should be preserved - at least when SBBSecho is in use. But other tossers could certainly strip them between systems. It's best
to not assume that all white-space characters are going to be preserved between FTN endpoints.
There are no other tossers in use here - its SBBS to SBBS. So is this a bug?
There is a parameter Strip Incoming Soft CRs which is set to "No" on the importing system, so I would expect that sbbsecho import the message verbatim?
If it doesnt work that way, can it be changed so that it does?
Because those are line-feeds and the FTSC specs say that line-feeds should be "ignored" (with no real definition of what "ignore" means).
Still, SBBSecho has an option to strip line-feeds and when not enabled, they should be preserved - at least when SBBSecho is in use.
to not assume that all white-space characters are going to be preserved between FTN endpoints.
I don't think so. SBBSecho currently *ignores* line-feeds characters from imported messages, per FTS-1 (sbbsecho.c lines 3486-87).
Line/paragraph-endings are represented in FTN messages with a carriage-return (0x0D) character. Is it possible that your originally posted message
didn't contain any carriage-returns? How was the message created exactly?
Re: Imported messages being modified
By: Digital Man to Alterego on Tue Oct 15 2019 10:14 am
Because those are line-feeds and the FTSC specs say that line-feeds should be "ignored" (with no real definition of what "ignore" means).
"Ignored" or "removed" - I agree it looks to be a vaguely written spec, IE: it could be interpretted both ways.
It says "All linefeeds, 0AH, should be ignored. Systems which display message text should wrap long lines to suit their application."
I would think its appropriate to intepret this as - ignore 0x0a in input (not remove it). And when you want to wrap long lines, wrap them how you want regardless of the presence of 0x0a (when you want to display it to a user). Thus, if you store it raw, and another process pulls it out of the message store - give it to that process raw, so that it can format it how it likes.
Still, SBBSecho has an option to strip line-feeds and when not enabled, they should be preserved - at least when SBBSecho is in use.
So SBBSecho can be configured to not "strip" line-feeds? How?
to not assume that all white-space characters are going to be preserved between FTN endpoints.
OK. But "in transit", it shouldnt be modified at all right?
I don't think so. SBBSecho currently *ignores* line-feeds characters from imported messages, per FTS-1 (sbbsecho.c lines 3486-87).
Err... SBBSecho currently *removes* line-feeds. :)
Line/paragraph-endings are represented in FTN messages with a carriage-return (0x0D) character. Is it possible that your originally posted message
didn't contain any carriage-returns? How was the message created exactly?
Yeah, thats my problem here - I'm sucking in the output from a unix app (gpg) - and thus line termination is 0x0a not 0x0d 0x0a.
My short term fix is to base64 encode the output before posting it to the message base :)
On 10-15-19 22:13, Digital Man wrote to Alterego <=-
Yeah, thats my problem here - I'm sucking in the output from a unix app (gpg) - and thus line termination is 0x0a not 0x0d 0x0a.
So the fix is to terminate the lines with CRLF - see exec/postmsg.js
for an example if you need one. SMB expects CRLF-terminated paragraphs/lines.
| Sysop: | MCMLXXIX |
|---|---|
| Location: | Prospect, CT |
| Users: | 325 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 12:20:30 |
| Calls: | 508 |
| Messages: | 219962 |