Tk Library Source Code

View Ticket
Login
Ticket UUID: 544453
Title: uuencode::uudecode and Trf 2.1p1
Type: Bug Version: None
Submitter: nobody Created on: 2002-04-16 00:34:47
Subsystem: base64 Assigned To: patthoyts
Priority: 5 Medium Severity:
Status: Closed Last Modified: 2002-04-17 06:34:09
Resolution: Fixed Closed By: patthoyts
    Closed on: 2002-04-16 23:34:09
Description:
I have written a script that connects to an nntp 
server and downloads a
message body into a string which in turn  gets all 
uuencoded attachments
processed and written to a directory as files.

First method I tried was opening a pipe to a uudecode 
program that I found.

This was fast and worked fine until people started 
posting yenc encoded
attachments to the newsgroup. The uudecode program 
would crash when it
encountered one of these.

Second method I tried was the uuencode package that is 
part of tcllib that
comes with Active Tcl 8.3.4.2.

This was a little slower and stack dumps on messages 
that the former method
was able to process correctly. I really liked that it 
returned a list of
lists that contained the filename mode and data.

Third method I tried was to get the Trf package which 
is used if available
by the uuencode package.

I can't get this method to work please help.

My platform is Windows 2000.

Below are two stack dumps
The first one is with the Trf directory removed from 
the lib directory.
Notice that the first message body is correctly 
processed.

The second dump is with Trf installed
notice that the first message body is not processed 
and that the errors are
different

Note I am only doing "package require uudecode" I let 
the uudecode package
find the Trf package

My function is included at the bottom it takes a 
string (message body) as an
argument
-------------------------------------------------------
-------
downloaded message 30543
decoded !krisp2_002.jpg

downloaded message 30544
invalid uuencoded string: length must be a multiple of 
4
    while executing
"decode [string range $line 1 end"
    ("true" arm line 7)
    invoked from within
"switch -exact -- $state {
            false {
                if {[regexp {^begin ([0-7]+) ([^\s]*)} 
$line  -> opts(mode)
opts
(name)]} {
             ..."
    (procedure "uuencode::uudecode" line 36)
    invoked from within
"uuencode::uudecode $message"
    (procedure "decode" line 3)
    invoked from within
"decode [ join $Vmessage  \n ]"
    (procedure "getmessages" line 24)
    invoked from within
"getmessages"
    (file "picker.tcl" line 59)
-------------------------------------------------------
-------
downloaded message 30543
::uuencode: wrong # args, all options require an 
argument
    while executing
"::uuencode -mode decode $s"
    (procedure "decode" line 2)
    invoked from within
"decode [string range $line 1 end"
    ("true" arm line 7)
    invoked from within
"switch -exact -- $state {
            false {
                if {[regexp {^begin ([0-7]+) ([^\s]*)} 
$line  -> opts(mode)
opts
(name)]} {
             ..."
    (procedure "uuencode::uudecode" line 36)
    invoked from within
"uuencode::uudecode $message"
    (procedure "decode" line 3)
    invoked from within
"decode [ join $Vmessage  \n ]"
    (procedure "getmessages" line 24)
    invoked from within
"getmessages"
    (file "picker.tcl" line 59)
-------------------------------------------------------
-

proc decode { message } {

    set name_mode_data [uuencode::uudecode $message]

    foreach { element } $name_mode_data {

        set name [ lindex $element 0 ]

        set Vfile [ open $name w ]

        fconfigure $Vfile -translation binary

        puts -nonewline $Vfile [ lindex $element 2 ]

        close $Vfile

        puts "decoded $name\n"

        flush stdout

        }

}
User Comments: patthoyts added on 2002-04-17 06:34:09:
Logged In: YES 
user_id=202636

Change and additional tests commited to the CVS HEAD.

patthoyts added on 2002-04-16 16:25:51:

File Added - 21278: bug544453.patch

Logged In: YES 
user_id=202636

There were two problems here. One is that the uudecode from
a file was failing to handle DOS line endings properly. The
other is to permit the decoder to handle unpadded lines more
gracefully. The attached patch handles both problems. The
decode procedure will now pad the input string to a multiple
of four if necessary. This should work ok for Trf as well -
although I havn't had a change to  check that yet.

I'll update the CVS repository when I get the chance
(tonight sometime (GMT)) and close the bug once the CVS has
been updated.

patthoyts added on 2002-04-16 15:53:04:

File Added - 21273: 30543.nws

nobody added on 2002-04-16 07:34:48:

File Added - 21254: 30544.nws

Attachments: