Hello All!

It has been reported to me that replies from areafix / filemgr within mbse have
only been terminated with a LF as in Linux text format recods etc.

Problem is I have at least one downlink that uses a Windows based product and is getting a flow of chars on one or more lines that are not formatted with LFCR :

Is there any way of dealing with this ?

And still cope with downlinks using Linux.



Vince

--- Mageia Linux v5/Mbse v1.0.6/GoldED+/LNX 1.1.501-b20150715
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1)

Hi,

On 2017-02-25 18:45:42, Vince Coen wrote to All:
about: "Line termination in msgs issued by mbse":

It has been reported to me that replies from areafix / filemgr within
mbse have only been terminated with a LF as in Linux text format
recods etc.

Problem is I have at least one downlink that uses a Windows based
product and is getting a flow of chars on one or more lines that are
not formatted with LFCR :

Is there any way of dealing with this ?

And still cope with downlinks using Linux.

It's not a matter of Windows or Linux. It's a matter of fidonet. FTS-0001 has this to say about it:


A 'hard' carriage return, 0DH, marks the end of a paragraph, and must
be preserved.

So called 'soft' carriage returns, 8DH, may mark a previous
processor's automatic line wrap, and should be ignored. Beware that
they may be followed by linefeeds, or may not.

All linefeeds, 0AH, should be ignored. Systems which display message
text should wrap long lines to suit their application.




Bye, Wilfred.


--- FMail-W32 1.73.17.78-B20170215
* Origin: Native IPv6 connectable node (2:280/464)

Hello Vince!

25 Feb 17 18:45, you wrote to all:

It has been reported to me that replies from areafix / filemgr within
mbse have only been terminated with a LF as in Linux text format
recods etc.

Fixed in 1.0.6.13.

Problem is I have at least one downlink that uses a Windows based
product and is getting a flow of chars on one or more lines that are
not formatted with LFCR :

Is there any way of dealing with this ?
And still cope with downlinks using Linux.

FTS-0001 specifies that CRs be preserved and LFs be ignored. Accordingly, 1.0.6.13 and later terminate the lines in the AreaMgr/FileMgr replies with CRs.

Andrew

--- GoldED+/LNX 1.1.5-b20161221
* Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)

Hello Wilfred!

25 Feb 17 21:32, you wrote to Vince Coen:

It's not a matter of Windows or Linux. It's a matter of fidonet.
FTS-0001 has this to say about it:

A 'hard' carriage return, 0DH, marks the end of a paragraph,
and must
be preserved.

So called 'soft' carriage returns, 8DH, may mark a
previous
processor's automatic line wrap, and should be ignored. Beware that
they may be followed by linefeeds, or may not.

All linefeeds, 0AH, should be ignored. Systems which display message
text should wrap long lines to suit their application.

v1.0.6.13 and later have been fixed to terminate the lines of the AreaMgr/FileMgr replies and notify messages with CRs instead of LFs.

Andrew

--- GoldED+/LNX 1.1.5-b20161221
* Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)

Hello Wilfred!

Saturday February 25 2017 21:32, you wrote to me:

Thanks for that Wilfred, so guess it is down to user's editor (Multimail/Darwin) not set up correctly one way or another.

This was his text msg:

-!-
Since The Eastern Star (whom I’ve been getting my main echo feed from) has shut down I linked to all the echos you have available and noticed a strange issue with either your Areafix, Synchronet or SBBSECHO.

Basically, some messages (such as the result of %ADD and %RESCAN) look fine but
others (such as the output from %HELP/%LIST) do not.

In any case, this is what I get in both MultiMail and on Synchronet itself:
-!-

First time anyone mentioned a problem.

I have passed on your response, thanks again,


Vince

Hi,

On 2017-02-25 18:45:42, Vince Coen wrote to All:
about: "Line termination in msgs issued by mbse":

It has been reported to me that replies from areafix / filemgr
within mbse have only been terminated with a LF as in Linux text
format recods etc.

Problem is I have at least one downlink that uses a Windows based
product and is getting a flow of chars on one or more lines that
are not formatted with LFCR :

Is there any way of dealing with this ?

And still cope with downlinks using Linux.

It's not a matter of Windows or Linux. It's a matter of fidonet.
FTS-0001 has this to say about it:

A 'hard' carriage return, 0DH, marks the end of a paragraph,
and must
be preserved.

So called 'soft' carriage returns, 8DH, may mark a
previous
processor's automatic line wrap, and should be ignored. Beware
that
they may be followed by linefeeds, or may not.

All linefeeds, 0AH, should be ignored. Systems which display
message
text should wrap long lines to suit their application.

Bye, Wilfred.

Vince

--- Mageia Linux v5/Mbse v1.0.6/GoldED+/LNX 1.1.501-b20150715
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1)

Hello Andrew!

Saturday February 25 2017 15:59, you wrote to me:

Hello Vince!

25 Feb 17 18:45, you wrote to all:

It has been reported to me that replies from areafix / filemgr
within mbse have only been terminated with a LF as in Linux text
format recods etc.

Fixed in 1.0.6.13.

Problem is I have at least one downlink that uses a Windows based
product and is getting a flow of chars on one or more lines that
are not formatted with LFCR :

Is there any way of dealing with this ?
And still cope with downlinks using Linux.

FTS-0001 specifies that CRs be preserved and LFs be ignored.
Accordingly, 1.0.6.13 and later terminate the lines in the
AreaMgr/FileMgr replies with CRs.

Thanks Andrew, I will download the latest snapshot and will recompil when I can
reboot the system to the other Mageia instance that does not suffer from not finding libiconv (despite the fact that I installed it from the gnu.org.



Vince

--- Mageia Linux v5/Mbse v1.0.6/GoldED+/LNX 1.1.501-b20150715
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1)