William Unruh wrote:
It seems that more and more people are posting as base64 encoded posts.
Presumably some idiotic reader is encoding news posts before posting.
slrn does not seem to translate these into something readable.
a) Is there some way of getting slrn to read these posts, other than to
save them unencode them and then read them? (Most of them turn out to be
not worth the effort)
b) if there is no way at present, could this feature be added to slrn?
not a problem here...
Welcome to the Emacs shell
~ $ slrn --version
slrn 1.0.3
S-Lang Library Version: 2.3.2
Operating System: Linux
COMPILE TIME OPTIONS:
Backends: +nntp +slrnpull +spool
External programs / libs: +canlock +inews +ssl +uudeview +iconv
Features: +decoding +emphasized_text +end_of_thread +fake_refs +gen_msgid
-grouplens -msgid_cache +piping +rnlock +spoilers -strict_from
Using 64 bit integers for article numbers.
DEFAULTS:
Default server object: nntp
Default posting mechanism: nntp
~ $
It seems that more and more people are posting as base64 encoded posts. Presumably some idiotic reader is encoding news posts before posting.
slrn does not seem to translate these into something readable.
a) Is there some way of getting slrn to read these posts, other than to
save them unencode them and then read them? (Most of them turn out to be
not worth the effort)
b) if there is no way at present, could this feature be added to slrn?
On 2022-05-09, issdr <p_u_n_k_i_n_d@yahoo.it> wrote:
William Unruh wrote:
It seems that more and more people are posting as base64 encoded posts.
Presumably some idiotic reader is encoding news posts before posting.
slrn does not seem to translate these into something readable.
a) Is there some way of getting slrn to read these posts, other than to
save them unencode them and then read them? (Most of them turn out to be >>> not worth the effort)
b) if there is no way at present, could this feature be added to slrn?
not a problem here...
Welcome to the Emacs shell
~ $ slrn --version
slrn 1.0.3
S-Lang Library Version: 2.3.2
Operating System: Linux
COMPILE TIME OPTIONS:
Backends: +nntp +slrnpull +spool
External programs / libs: +canlock +inews +ssl +uudeview +iconv
These are the only differences with mine. -canlock, -ssl -uudeview
instead of your +s.
Not sure which of those three would make the differnce.
Features: +decoding +emphasized_text +end_of_thread +fake_refs +gen_msgid >> -grouplens -msgid_cache +piping +rnlock +spoilers -strict_from
Using 64 bit integers for article numbers.
DEFAULTS:
Default server object: nntp
Default posting mechanism: nntp
~ $
On 2022-05-09, issdr <p_u_n_k_i_n_d@yahoo.it> wrote:
External programs / libs: +canlock +inews +ssl +uudeview +iconv
These are the only differences with mine. -canlock, -ssl -uudeview
instead of your +s.
Not sure which of those three would make the differnce.
It seems that more and more people are posting as base64 encoded posts.
Presumably some idiotic reader is encoding news posts before posting.
slrn does not seem to translate these into something readable.
a) Is there some way of getting slrn to read these posts, other than to
save them unencode them and then read them? (Most of them turn out to be
not worth the effort)
b) if there is no way at present, could this feature be added to slrn?
slrn has base64 decoding built-in, as I recall. Can you just pretend the post is a binary?
Lewis:
slrn has base64 decoding built-in, as I recall. Can you just pretend the post
is a binary?
As the OP's slrn was compiled without the uudeview configure-option, it
is quite normal that slrn does not automatically decode the posts
concerned.
I just checked my own configure-option and can confirm that *+uudeview* appears do be a default: I have not activated it explicitly. The only available options in the configure script are anyway
------------
--with-uu=DIR Use DIR/lib and DIR/include for uu
--with-uulib=DIR uu library in DIR
--with-uuinc=DIR uu include files in DIR
------------
I venture, that either the OP's slrn is strange in some way or that
he compiled it himself without having development-versions of the named libraries installed... or something else with the same effect.
Maybe a binary slrn will notice the absence of ordinary runtime versions
of the libraries and display -uudeview. But I know nothing about that.
My version decodes alright:
----------------
alucard@crypt:~$ slrn --version
slrn 1.0.3
Version der S-Lang-Bibliothek: 2.3.2
Betriebssystem: Linux
COMPILE TIME OPTIONS:
Backends: +nntp +slrnpull +spool
External programs / libs: +canlock +inews +ssl +uudeview +iconv
Features: +decoding +emphasized_text +end_of_thread +fake_refs +gen_msgid
-grouplens -msgid_cache +piping +rnlock +spoilers -strict_from
Using 64 bit integers for article numbers.
----------------
Cheerio
Just to add definitelness here is the latest post of this type I ran
acress. But I have probably run across about 10 of them in the past few months
Where do I find the uudeview library (if that is what it is called).
It seems that Mageia does not have them?
Where do I find the uudeview library (if that is what it is called).
OK, I am simply using my distribution (Mageia 8) version of slrn.
So I guess I am going to have to recompile it for myself and put in a
bug report to the distribution.
Thanks for the suggestions.
Where do I find the uudeview library (if that is what it is called).
It seems that Mageia does not have them?
that's a multipart, gpg signed message, not simply a base64 encoded
post.
https://user.fm/files/v2-838561f84fe4c1c18c853f227cbe9255/Clipboard.png
this is how i got to view it properly in slrn, *almost* (bad, weird line ends). there might be better, simpler ways, hope someone here knows how
to and is willing to share.
this is how i got to view it properly in slrn, *almost* (bad, weird line ends). there might be better, simpler ways, hope someone here knows how
to and is willing to share.
FWIW, I just have `interpret "mime.sl"` and I can read multipart
messages just fine, I've never noticed any line ending problems.
Tavis Ormandy wrote:
FWIW, I just have `interpret "mime.sl"` and I can read multipart
messages just fine, I've never noticed any line ending problems.
i followed up to my own post. not a regular user here, i found that out
right after doing such a mess...
btw, could you check that message on linux.debian.devel and see whether
you get those nasty cr's too?
Ahh - you're right, it seems like Thunderbird users are sending CRLF
line endings. That's weird.
You could try a patch to mime.sl like this:
On 2022-05-10, issdr wrote:
this is how i got to view it properly in slrn, *almost* (bad, weird line
ends). there might be better, simpler ways, hope someone here knows how
to and is willing to share.
Hmm - it's not clear to me what mime-support.sl does that just the plain mime.sl that comes with slrn doesn't do?
Where is mime.sl
Lewis wrote:
Where is mime.sl
~ $ wget http://jedsoft.org/releases/slrn/slrn-1.0.3a.tar.bz2
--2022-05-13 23:13:13-- http://jedsoft.org/releases/slrn/slrn-1.0.3a.tar.bz2 Resolving jedsoft.org (jedsoft.org)... 199.180.249.46
Connecting to jedsoft.org (jedsoft.org)|199.180.249.46|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 997138 (974K) [application/x-gtar-compressed]
Saving to: ‘slrn-1.0.3a.tar.bz2’
slrn-1.0.3a.tar.bz2 100%[===================>] 973.77K 989KB/s in 1.0s
2022-05-13 23:13:14 (989 KB/s) - ‘slrn-1.0.3a.tar.bz2’ saved [997138/997138]
~ $ tar -tvf slrn-1.0.3a.tar.bz2 | grep mime\.sl
-rw-rw-r-- root/root 14440 2016-10-24 00:34 slrn-1.0.3/macros/mime.sl
~ $ tar -tvf slrn-1.0.3a.tar.bz2 | grep mime\.sl
-rw-rw-r-- root/root 14440 2016-10-24 00:34 slrn-1.0.3/macros/mime.sl
Hmm.. I wonder why homebrew has elided that file then.
Lewis wrote:
~ $ tar -tvf slrn-1.0.3a.tar.bz2 | grep mime\.slHmm.. I wonder why homebrew has elided that file then.
-rw-rw-r-- root/root 14440 2016-10-24 00:34 slrn-1.0.3/macros/mime.sl >>
~ % brew ls --verbose slrn | grep mime /usr/local/Cellar/slrn/1.0.3a_1/share/slrn/slang/mime.sl
(or `locate mime.sl' in case you've trained it)
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 307 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 105:54:03 |
| Calls: | 6,852 |
| Calls today: | 3 |
| Files: | 12,355 |
| Messages: | 5,415,735 |
