headers
Urs Janßen | 20 Aug 2010 01:08

[tin 1.9.x] problem with Multipart/Mixed and text/plain iso-10646-ucs-2 base64 parts

When reading a gated malinglist I noticed that tin didn't display a
text/plain part in an multipart article. This might be related to 
iconv (linux glibc 2.7 iso-8859-1 env. and linux eglibc 2.11.2 utf-8 env.)
not knowing(?) iso-10646-ucs-2 (but ISO-10646/UCS2), but tin puts (too few
bytes of) garbage on the screen instead of expected '?'s. Anyone willing to
look into this? The mime structure is the following:

Mime-Version: 1.0
Content-Type: Multipart/Mixed;
  boundary="Boundary-00"

--Boundary-00
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

foo

--Boundary-00
Content-Type: text/plain;
  charset="iso-10646-ucs-2";
  name="bar.txt"
Content-Transfer-Encoding: base64
Content-Disposition: inline

/v8AuwBKAPYAcgBnACAAbQD2AGMAaAB0AGUAIABmAPwAbgBmACAARgByAPwAaABzAHQA/ABj
AGsAcwBiAHIA9gB0AGMAaABlAG4AIAB1AG0AIADkAHUA3wBlAHIAcwB0AGUAcwAgAFYA9gBs
AGwAZQBnAGUAZgD8AGgAbAAgAHoAdQAgAHMAcAD8AHIAZQBuAC4AqwAK
(Continue reading)

Permalink | Reply | 2 comments |
headers
Urs Janßen | 27 Aug 2010 16:05

[tin 1.9.5] documentation? missmatch quick_kill_header vs. default_filter_kill_header

tin(5) says:
|      quick_kill_header
|           Identical   to   the    tinrc    variable default_fil-
|           ter_kill_header

tinrc and tin(1) says:
|# header=NUM  0,1=Subject: 2,3=From: 4=Message-ID: & full References: line
|#             5=Message-ID: & last References: entry only
|#             6=Message-ID: entry only 7=Lines:

attributes says:
|#    0=subj (case sensitive) 1=subj (ignore case)
|#    2=from (case sensitive) 3=from (ignore case)
|#    4=msgid 5=lines

lines filter is 7 not 5 and where are the filter types 5 and 6 in attributes?

I guess this is just a documentation issue but didn't verify that.
Permalink | Reply | 1 comment |
headers
Urs Janßen | 27 Aug 2010 16:14

Re: [tin 1.9.x] problem with Multipart/Mixed and text/plain iso-10646-ucs-2 base64 parts

On Fri, Aug 20, 2010 at 01:08:32AM +0200, Urs Janßen wrote:
> When reading a gated malinglist I noticed that tin didn't display a
> text/plain part in [...] iso-10646-ucs-2

root cause are possible NULL bytes in a multibyte char (in UTF-16, UTF.32,
...) but we are using string functions...
a trivial "workaround" would be to assemble a list of charsets which may
contain NULL bytes and tell tin to skip parts in that charset.
a partical fix would be to fix just the charset conversion, a real fix might
be much more complicated as tins code also relies on not seeing any 0 bytes
when reading an article from disk/net.
Permalink | Reply | 1 comment |
headers
Dennis Preiser | 27 Aug 2010 18:20
Picon
Picon

Re: [tin 1.9.5] documentation? missmatch quick_kill_header vs. default_filter_kill_header

On Fri, Aug 27, 2010 at 04:05:56PM +0200, Urs Janßen wrote:
> tin(5) says:
> |      quick_kill_header
> |           Identical   to   the    tinrc    variable default_fil-
> |           ter_kill_header
> 
> tinrc and tin(1) says:
> |# header=NUM  0,1=Subject: 2,3=From: 4=Message-ID: & full References: line
> |#             5=Message-ID: & last References: entry only
> |#             6=Message-ID: entry only 7=Lines:
> 
> attributes says:
> |#    0=subj (case sensitive) 1=subj (ignore case)
> |#    2=from (case sensitive) 3=from (ignore case)
> |#    4=msgid 5=lines
> 
> lines filter is 7 not 5 and where are the filter types 5 and 6 in attributes?
> 
> I guess this is just a documentation issue but didn't verify that.

Documentation issue. From attrib.c:set_default_attributes():

	attributes->quick_kill_header = tinrc.default_filter_kill_header;

so, if this attribute is not set from the attributes file, the tinrc
value is used.

Dennis
(Continue reading)

Permalink | Reply | 0 comments |

Gmane