Red Hat Bugzilla – Bug 770782
mutt does not handle attachments properly with an existing mailcap file
Last modified: 2012-01-05 14:12:50 EST
Description of problem:
Assume that one of mail message attachments is a some_picture.jpg JPEG file and mutt read this message and that we are in attachment menu. Putting a cursor on 'some_picture.jpg' entry and hitting return results in an alert with:
No images found in 'file:///tmp/some_picture.jpg'.
Closer check reveals that mutt does write /tmp/some_picture.jpg but with
image/*; /usr/bin/xdg-open %s
entry in /etc/mailcap fails to handle it. This does work if /etc/mailcap line is replaced with
image/*; /usr/bin/xdg-open %s ; copiousoutput
The same goes if an attachment is of application/pdf type and the same cure applies. I strongly suspect that this will be also the case with every MIME type where an external handler is required although I bumped into that with images and checked for PDF too but not for anything else.
Version-Release number of selected component (if applicable):
I know for sure that sometime in the past mutt in Fedora 14 did NOT require 'copiousoutput' and worked without that fine but I cannot tell now if this was the case with the latest F14 updates. I can confirm, though, that
mutt-126.96.36.199-3.0.2.el5 has not problems with "missing" 'copiousoutput'. I cannot tell if this change was deliberate; I failed to find anything on this in ChangeLog.
Additional check reveal that these are entries with /usr/bin/xdg-open, or apparently some other intermediary shell script, which require 'copiousoutput'.
That means that with 'application/pdf' this does NOT work:
application/pdf; /usr/bin/xdg-open %s
but either of the following two (assuming evince installed):
application/pdf; evince %s
application/pdf; /usr/bin/xdg-open %s ; copiousoutput
Hm, that likely means this this worked with mutt-188.8.131.52-3.0.2.el5 just because
a corresponding mailcap entry was of a type 'application/pdf; evince %s'.
Hi, I see the same behavior, but /etc/mailcap is a part of mailcap package, so re-assigning this bug to that one.
*** This bug has been marked as a duplicate of bug 653249 ***