Hey Mary!

First ever posting from the newfangled wireless open mesh access point and three way bottle opener.

It had to happen.

Life is good,
Maurice

... A M|+|+se once bit my sister ...
--- GNU bash, version 4.4.12(1)-release (x86_64-unknown-linux-gnu)
* Origin: Pointy Stick Society - Ladysmith BC, Canada (1:153/7001.250)

Hello Guy!

16 May 2017 21:56, Guy Robot wrote to Mary Mainframe:

Hey Mary!

CCR

who the heck is Guy ?


Regards Benny

... there can only be one way of life, and it works :)

--- Msged/LNX 6.2.0 (Linux/4.11.0-gentoo (i686))
* Origin: openvpn on its way here (2:230/0)

Hey Benny!

who the heck is Guy ?

"Guy Robot" is a play on words from Isaac Asimov's book title "I, Robot".

Life is good,
Maurice

... Don't cry for me I have vi.
--- GNU bash, version 4.4.12(1)-release (x86_64-unknown-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Hello Maurice!

17 May 2017 01:50, Maurice Kinal wrote to Benny Pedersen:

who the heck is Guy ?

"Guy Robot" is a play on words from Isaac Asimov's book title "I,
Robot".

ah thats why i dont know him, never reading books, i am more learn from expirences :=)


Regards Benny

... there can only be one way of life, and it works :)

--- Msged/LNX 6.2.0 (Linux/4.11.1-gentoo (i686))
* Origin: openvpn on its way here (2:230/0)

Hey Benny!

ah thats why i dont know him, never reading books

There was also a movie called "I, Robot".

Life is good,
Maurice

... Don't cry for me I have vi.
--- GNU bash, version 4.4.12(1)-release (x86_64-unknown-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Hello Maurice!

20 May 2017 06:31, Maurice Kinal wrote to Benny Pedersen:

ah thats why i dont know him, never reading books

There was also a movie called "I, Robot".

i-pod, i-pad, iphone :=)

ios, bah


Regards Benny

... there can only be one way of life, and it works :)

--- Msged/LNX 6.2.0 (Linux/4.11.2-gentoo (i686))
* Origin: openvpn on its way here (2:230/0)

Hey Benny!

i-pod, i-pad, iphone :=)

Ah! Now we have i-bot ... or guy-bot if you prefer.

ios, bah

Bah! Det er til sm|N b|+rn. :::onde grin:::

Life is good,
Maurice

... Don't cry for me I have vi.
--- GNU bash, version 4.4.12(1)-release (x86_64-unknown-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Hello, Maurice Kinal.
On 23/05/2017 9.40 PM you wrote:

Bah! Det er til sm|N b|+rn. :::onde grin:::

Pure 7bit, imho not intended since HotDogED did not convert it to correct display

--
Benny
--- Hotdoged/2.13.5/Android
* Origin: this not my chromebook (2:230/38.1)

Hey Benny!

Pure 7bit, imho not intended

It is still utf-8 here so HotDogED didn't screw with it even if it shows there as 7bit characters.

since HotDogED did not convert it to correct display

Tsk, tsk. That is very, very sad.

Speaking of which, I was reading that the new google wireless mesh app for android smartphones has a native utf-8 text messaging thingy built into it. However it does have a character limit although I forget what it is. My Fidonet meshing messaging thingy has no such limit.

How about yours? :::snicker:::

Life is good,
Maurice

... Don't cry for me I have vi.
--- GNU bash, version 4.4.12(1)-release (x86_64-unknown-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

On 2017 May 26 05:54:24, you wrote to Benny Pedersen:

Hey Benny!

Pure 7bit, imho not intended

It is still utf-8 here so HotDogED didn't screw with it even if it shows there as 7bit characters.

yeah but your original didn't carry any indicator of what character set was in use... it showed up over here as UTF-8 but no way to convert without the character set control line...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... ASKHOLE: (n) someone who asks many stupid, pointless or obnoxious questions.
---
* Origin: (1:3634/12.73)

On 2017 May 23 21:40:16, you wrote to Benny Pedersen:

@MSGID: 1:153/7001 5924ac40
@REPLY: 2:230/0 5924c419
Hey Benny!

i-pod, i-pad, iphone :=)

Ah! Now we have i-bot ... or guy-bot if you prefer.

ios, bah

Bah! Det er til sm|N b|+rn. :::onde grin:::

Life is good,
Maurice

... Don't cry for me I have vi.
--- GNU bash, version 4.4.12(1)-release (x86_64-unknown-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001) SEEN-BY: 116/116 135/300 140/1 153/7001 154/10 20 30 40 700 227/201

229/310

SEEN-BY: 261/38 340/800 3634/12 15 22 24 27 50
@PATH: 153/7001 154/10 3634/12

see what i mean about no character set control line? without it there's no way for any system to know what character set to use and whether or not to convert it to another...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... A lion never looses sleep over the opinions of sheep.
---
* Origin: (1:3634/12.73)

Hello mark!

26 May 17 06:26, you wrote to Maurice Kinal:

see what i mean about no character set control line? without it there's no way for any system to know what character set to use and whether or not to convert it to another...

I do not agree. Using different character encodings is not limited to
fidonet. Over the years some nice tools/libraries have been developed to
define the possibly used encoding. The only thing is that the use of
these methods have not been implemented in Fidonet software.

I tried a simple message reader that uses a tweaked version of one of these
tools, and I can assure you that the results are far better than honoring
the characterset controlline. The encodings advertised are not always the
ones that are really used.

I presume that Maurice does something similar. Where I do not agree with
Maurice is that, as he has no need for the characterset controlline, he does
not add one to his messages. It would be a nice guesture if he did, as a
service to backward compatibillity.

Omitting the characterset controlline puts Maurices messages in the same
class as messages origination from software that predates the standard.

Most readers then make a fixed assumption on the encoding. Applying that
assumption on UTF-8 encoded messages is not a good idea.

It would be nice if coders of actively maintained message editors would
consider to include the guessing tools in their software and ignore the
the CRHS: kludge.

But to be honest, that can only be a pipe dream.

Kees

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

Hey mark!

yeah but your original didn't carry any indicator of what
character set was in use

utf-8 characters are easy to identify. There is no character set as such and anyone requiring an indicator obviously doesn't understand how utf-8 works. Putting a brain dead CHRS kludge doesn't work and never will for utf-8.

Life is good,
Maurice

... Don't cry for me I have vi.
--- GNU bash, version 4.4.12(1)-release (x86_64-unknown-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Hey mark!

see what i mean about no character set control line?

I fail to see your point. If you cannot readily see that those are Danish characters then obviously you shouldn't be converting them since they cannot be
converted to CP437 which is what CHRS kludge you are currently flying for some reason. If they were 8 bit characters, such as latin1, then they would require
conversion which of course you cannot do since those characters don't exist in CP437. Thus putting a CHRS kludge for utf-8 is a total waste of bytes seeing that it will never work, especially given the total lack of understanding within the FTSC of how things REALLY work, nevermind on how they should or shouldn't be implimented.

without it there's no way for any system to know what character
set to use and whether or not to convert it to another...

Don't bother converting and everything will be just fine. Conversion of utf-8 characters to an impossible 8 bit character set is an exersize in futility and just ends up annoying those who don't require any dumbass, corrupt FTN control line to see the obvious and deal with it properly.

Life is good,
Maurice

... Don't cry for me I have vi.
--- GNU bash, version 4.4.12(1)-release (x86_64-unknown-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Hey Kees!

I presume that Maurice does something similar.

Not quite. I used to convert but gave it up as an exersise in futility as you point out.

Where I do not agree with Maurice is that, as he has no need for
the characterset controlline, he does not add one to his
messages. It would be a nice guesture if he did, as a service to
backward compatibillity.

Backwards compatible to what? An FTN compliant UTF-8 messaging system never existed before and arguably I am the only one getting it correctly today. All the control lines in the universe won't alter that fact.

For the record I started putting in the bogus "CHRS: UTF-8 4" one way back when. It quickly became obvious that it would never work and only served to promote the scam. It most definetly isn't needed.

Life is good,
Maurice

... Don't cry for me I have vi.
--- GNU bash, version 4.4.12(1)-release (x86_64-unknown-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

On 2017 May 26 12:42:26, you wrote to me:

see what i mean about no character set control line?

I fail to see your point. If you cannot readily see that those are Danish characters then obviously you shouldn't be converting them since they cannot be converted to CP437 which is what CHRS kludge you are currently flying for some reason.

i can't convert them because all i see is two bytes for each character... if the message carried a character set control line, my system would have a better
chance at displaying them properly for me no matter what character set i /write/ with... consider if i read everything in UTF-8 but write in CP437... the character set control line is to help others know what you used when you wrote the message so they can display it correctly... or at least try to by converting it to the local character set of their local display...

in other words, what character set i read in should not matter one iota to you... what character set i write in is what should concern you so your system can possibly convert and display my message in your local character set...

)\/(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 left me without a reason, don't come back with an excuse.
---
* Origin: (1:3634/12.73)

Hey mark!

what character set i read in should not matter one iota to you

Then you'll be happy to know that it doesn't. In fact it doesn't matter one iota to me if you don't use the CHRS control line.

so your system can possibly convert and display my message

If it actually ever contained any CP437 characters EVER then it might be an issue but I doubt it would. I do check by hand every once and awhile when a Russian sysop claims CP866 and actually has some CP866 characters in their message but haven't done that for quite some time. The last time I saw any actual CP437 characters in a fidonet message none of them had anything to do with text, they were line drawing characters used for so-called ascii art which
of course is wrong since CP437 characters are not ascii no matter what any misguided sysop claims.

display my message in your local character set

No matter what, your messages always display fine in utf-8 despite the fact they never are any 8 bit or multibyte characters. Even if there were it wouldn't matter any. Of course the other way around - you displaying utf-8 characters in any character set other than utf-8 - will never ever work no matter what I put in a control line. It will never, ever work especially not utf-8 Dansk characters <-> CP437. Also cyrillic languages which seems the more
likely scenerio in this particular echo (Russian sysops and CP866). It cannot be done, with or without a CHRS control line.

Life is good,
Maurice

... Don't cry for me I have vi.
--- GNU bash, version 4.4.12(1)-release (x86_64-unknown-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Hello Benny!

26 May 2017 02:09, Benny Pedersen wrote to Maurice Kinal:

Hello, Maurice Kinal.
On 23/05/2017 9.40 PM you wrote:

Bah! Det er til sm|N b|+rn. :::onde grin:::

Pure 7bit, imho not intended since HotDogED did not convert it to
correct display

damm it did above is correct latin-1, so it did something right imho, its was just not rendered unicode on my android, hmm

--
Benny
-+- Hotdoged/2.13.5/Android
+ Origin: this not my chromebook (2:230/38.1)

Regards Benny

... there can only be one way of life, and it works :)

--- Msged/LNX 6.2.0 (Linux/4.11.2-gentoo (i686))
* Origin: openvpn on its way here (2:230/0)

Hello Maurice!

26 May 2017 05:54, Maurice Kinal wrote to Benny Pedersen:

Hey Benny!

Pure 7bit, imho not intended

It is still utf-8 here so HotDogED didn't screw with it even if it
shows there as 7bit characters.

no you get latin-1 back from me with that above reply, it was showed perfect on
my gentoo

since HotDogED did not convert it to correct display

Tsk, tsk. That is very, very sad.

yes its internal works with unicode, but not on screen display part of it

Speaking of which, I was reading that the new google wireless mesh app for android smartphones has a native utf-8 text messaging thingy built into it. However it does have a character limit although I forget
what it is. My Fidonet meshing messaging thingy has no such limit.

i have asus thinker with android now :=)

How about yours? :::snicker:::

expand your microsd drive, or usb harddisk, google PiDrive

install android then, it will be my next gadget, what about yours ? :=)


Regards Benny

... there can only be one way of life, and it works :)

--- Msged/LNX 6.2.0 (Linux/4.11.2-gentoo (i686))
* Origin: openvpn on its way here (2:230/0)

Hello mark!

26 May 2017 06:25, mark lewis wrote to Maurice Kinal:

yeah but your original didn't carry any indicator of what character
set was in use... it showed up over here as UTF-8 but no way to
convert without the character set control line...

confusing part is that my reply was rendered latin-1 where it shows intended converting did work, hmm

all i just missed was to see the rendered unicode

so default is that if no charset is defined, let it show as 7bit

Maurice can you fix this ?


Regards Benny

... there can only be one way of life, and it works :)

--- Msged/LNX 6.2.0 (Linux/4.11.2-gentoo (i686))
* Origin: openvpn on its way here (2:230/0)

Hello Maurice!

26 May 2017 12:12, Maurice Kinal wrote to mark lewis:

utf-8 characters are easy to identify. There is no character set as
such and anyone requiring an indicator obviously doesn't understand
how utf-8 works.

oh, have iconv autodetect source charset ? :)

Putting a brain dead CHRS kludge doesn't work and
never will for utf-8.

what was the problem ?

unicode is only 7bit and should be shown as so, if nothing else are asked from the sender


Regards Benny

... there can only be one way of life, and it works :)

--- Msged/LNX 6.2.0 (Linux/4.11.2-gentoo (i686))
* Origin: openvpn on its way here (2:230/0)

Hey Benny!

damm it did above is correct latin-1,

No it isn't, or at least the character codes in the file aren't. They are still utf-8. However some editors are able to display certain utf-8 characters
as latin1 characters to the screen as long as they are legitimate latin1 characters whose utf-8 leading byte is 0xc3. The small angstrom (|N) and the small slashed o (|+) in 8 bit character displays will both have the 0xc3 leading byte which belongs to the latin1 subset of utf-8.

so it did something right

Yes but that is limited to iso-8859-1 (aka latin1) characters.

imho, its was just not rendered unicode on my android, hmm

Exactly. However that only works with latin1 characters since 0x0e5 (utf-8) happens to correspond to 0xe5 in latin1. However that will never work with any
other character set such as CP437 or CP866 but they should still show as 0xc3 for the leading byte in any half decent hex editor. For completeness the small
angstrom's trailing byte is 0xa5 while it is 0xb8 for the slashed o. Note all bytes, leading and trailing, are all 8 bit and NEVER 7 bit which are reserved as ASCII characters (0x00 - 0x7f).

Life is good,
Maurice

... Don't cry for me I have vi.
--- GNU bash, version 4.4.12(1)-release (x86_64-unknown-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Hey Benny!

no you get latin-1 back from me with that above reply

Nope. I just looked and they show as 0x0E5 (U+00E5) and 0x0F8 (U+00F8) which are mutilbyte (16 bit) utf-8 characters exactly the same as they were sent. If
they were truly latin1 then they would be 8 bit characters 0xE5 and 0xF8 which they aren't but to a half decent modern text editor would be displayed as such even though that isn't the reality of the situation. That only works with latin1 characters and not latin-1 characters whatever they really are. You've obviously are misinformed about legitimate iso-8859-1 aliases.

install android then, it will be my next gadget, what about yours

I prefer big boy toys that come with a native c compiler such as gcc. I doubt Android will ever become a real unixie operating system since it lacks far too much to earn the name unixie, one of which is a native c compiler.

Life is good,
Maurice

... Don't cry for me I have vi.
--- GNU bash, version 4.4.12(1)-release (x86_64-unknown-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Hey Benny!

confusing part is that my reply was rendered latin-1

Probably latin1 and like I said previously half decent editors these days can display the latin1 utf-8 subset as 8 bit latin1 characters to the screen/display while retaining the utf-8 codes within the file. That is what you saw happening.

let it show as 7bit

Nope. Those are reserved for true ascii characters. What you REALLY mean is 8bit and furthermore only latin1 which will always have a leading 0xc3 byte for
latin1 text characters. There are a few 0xc2 characters but they are symbols for the mostpart such as monetary and math symbols etc.

Maurice can you fix this ?

It was never broken. You are jnot looking at it correctly as well as using the
wrong alias for iso-8859-1. The FTN document is also wrong but then they always are aren't they? ;-)

Life is good,
Maurice

... Don't cry for me I have vi.
--- GNU bash, version 4.4.12(1)-release (x86_64-unknown-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Hey Benny!

oh, have iconv autodetect source charset ? :)

Some people do that. Personally I think it is a waste of time but it was an interesting exercize way back when. I even posted my results in this echo back
then.

unicode is only 7bit

Only the REAL ascii characters. Never anything else such as any native IBM/MS encodings.

Life is good,
Maurice

... Don't cry for me I have vi.
--- GNU bash, version 4.4.12(1)-release (x86_64-unknown-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Hello, Maurice Kinal.
On 26/05/2017 1.02 PM you wrote:

Where I do not agree with Maurice is that, as he has no need for
the characterset controlline, he does not add one to his
messages. It would be a nice guesture if he did, as a service to
backward compatibillity.

Backwards compatible to what? An FTN compliant UTF-8 messaging
system never existed before and arguably I am the only one getting
it correctly today. All the control lines in the universe won't
alter that fact. For the record I started putting in the bogus
"CHRS: UTF-8 4" one way back when. It quickly became obvious that
it would never work and only served to promote the scam. It most definetly isn't needed.

Holmegords olfabrikker servere kolde sodavand til forbigoende campister med ?? anhungere ??

All we need is emotions

Beat me

--
Benny
--- Hotdoged/2.13.5/Android
* Origin: this not my chromebook (2:230/38.1)

Hey Benny!

All we need is emotions

I am holding out for the cash.

Life is good,
Maurice

... Don't cry for me I have vi.
--- GNU bash, version 4.4.12(1)-release (x86_64-bonnell-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Hey Benny!

All we need is emotions

A bit of coding skills will get you further and faster.

Life is good,
Guy Robot

... There are 206 days until the next cybertoast.
--- GNU bash, version 4.4.12(1)-release (x86_64-silvermont-linux-gnu)
* Origin: Pointy Stick Society - Ladysmith BC, Canada (1:153/7001.250)

Hey Benny!

I forgot to check out BBBS to see if it's so-called LATIN-1 can handle your so-called LATIN-1. OF course both of them are really LATIN1 but who would know
except someone like me?

Holmegords olfabrikker servere kolde sodavand til forbigoende campister med ??
anhungere ??
All we need is emotions
Beat me

Looks okay from this angle. We'll see if it survives the trip.

Life is good,
Maurice

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

Hey Maurice!

----- "<Esc>:read !./msg-read.sh 1 | iconv -f latin1 | sed -n '/^>/p'" starts >Holmeg|Nrds |+lfabrikker servere kolde sodavand til forbig|Nende campister med
??

anh|angere ??
All we need is emotions
Beat me

----- "<Esc>:read !./msg-read.sh 1 | iconv -f latin1 | sed -n '/^>/p'" ends

It is too easy when it is done correctly.

Life is good,
Maurice

... Don't cry for me I have vi.
--- GNU bash, version 4.4.12(1)-release (x86_64-bonnell-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Hello Benny!

07 Jun 2017 05:43, Benny Pedersen wrote to Maurice Kinal:

Holmegords olfabrikker servere kolde sodavand til forbigoende
campister med ?? anhungere ??

damm latin-1 does kill emoties


Regards Benny

... there can only be one way of life, and it works :)

--- Msged/LNX 6.2.0 (Linux/4.11.4-gentoo (i686))
* Origin: openvpn on its way here (2:230/0)