[Mimedefang] $fname in filter() is an array reference
Matt Garretson
mattg at assembly.state.ny.us
Mon Mar 1 18:05:38 EST 2010
I've noticed this for a while, but have only now gotten around to
looking into it. Maybe it doesn't matter, but I just figured I'd
mention it. This is MD version 2.68 on Fedora 12 (as well as
previous versions of both) ...
In mimedefang-filter, both filter() and filter_multipart() are
passed a value ($fname in the example filter) that is supposed to
be a string containing a suggested filename for the entity.
However, what's really getting passed is an array reference. (If
you print $fname, you'll get "ARRAY(0x3ee5968)" or some such.)
I think this is because of the way $fname is defined in
rebuild_entity() in mimedefang.pl :
my($fname) = takeStabAtFilename($in);
My understanding is that the parens cause takeStabAtFilename() to
be called in a list context, which in turn for is causing MIME-tools'
decode_mimewords() to return an array rather than a scalar. The
attached trivial patch to mimedefang.pl.in ditches the parens,
causing $fname to be a scalar string as documented within MIMEdefang.
Now, the man page for MIME::Words says that forcing decode_mimewords()
to return a scalar is "probably not what you want", but it certainly
is easier to deal with, and it matches the MD's comments and docs.
I don't know what bad side effects my patch might cause, but
hopefully those smarter than I here can shed some light on it.
Thanks!
-Matt
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch.txt
URL: <https://lists.mimedefang.org/pipermail/mimedefang_lists.mimedefang.org/attachments/20100301/57fb8911/attachment.txt>
More information about the MIMEDefang
mailing list