Bug 653249 - Mutt cannot open attachments w. xdg-open
Summary: Mutt cannot open attachments w. xdg-open
Alias: None
Product: Fedora
Classification: Fedora
Component: xdg-utils
Version: rawhide
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Rex Dieter
QA Contact: Fedora Extras Quality Assurance
: 770782 (view as bug list)
Depends On: 571932
TreeView+ depends on / blocked
Reported: 2010-11-15 04:17 UTC by Dave Botsch
Modified: 2020-12-03 19:47 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Last Closed:
Type: ---

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
FreeDesktop.org 32016 0 None None None Never

Description Dave Botsch 2010-11-15 04:17:20 UTC
Description of problem:

Fedora 13, like earlier Fedora releases, defaults to xdg-open for opening files of whatever type. xdg-open then calls the appropriate viewer to actually open the file.

In Fedora 13 (unlike 11), xdg-open forks off the viewing application and returns. This causes problems with mutt.

Mutt, upon the application called to view the attachment (by system default, xdg-open) returning, deletes the temporary file in /tmp . This essentially causes a race condition... the viewer pops up saying that no such file exists... eg:

No images found in 'file:///tmp/DSC00817.JPG'.

Version-Release number of selected component (if applicable):

How reproducible:
100% of time

Steps to Reproduce:
1. install fedora 13, including mutt and xdg-utils
2. send yourself an email with an attachment, such as a JPG file
3. open the email
4. press 'v' to view the parts of the email
5. cursor down to the JPG and press RETURN
6. xdg fires off Eye of GNome Image Viewer, which returns a File Not Found error such as:
No images found in 'file:///tmp/DSC00817.JPG'.
Actual results:
Image does not open in viewer

Expected results:
Image opens in external viewer

Comment 1 Miroslav Lichvar 2010-11-26 15:16:26 UTC
Hm, this looks like an xdg-open problem that it doesn't wait before the file is actually opened, not sure if it's possible to fix it without reverting to the blocking behavior. Maybe this could be enabled with a command line option or an environment variable?

A workaround is to add the needsterminal flag to the mailcap entry, so mutt waits for a key press before removing the file in tmp.

Comment 2 Rex Dieter 2010-11-26 15:54:16 UTC
Yeah, not all helper applications wait before returning (kde-open in particular is one example).  Not much xdg-utils can do about that.

Comment 3 Dave Botsch 2010-12-01 00:16:30 UTC
Well, xdg-utils can fix xdg-open, at least.

But either xdg-open or mutt needs to be fixed. The interesting question is which.

And while one could argue that any mutt users are confortable editing the mailcap entries, one should not have to. And, does adding "needsterminal" flag to mailcap entries break anything else? More importantly, does adding this flag then break rpms from being able to update the mailcap on their own?

Comment 4 Rex Dieter 2010-12-01 13:33:39 UTC
kde-open has a --tempfile option, that could be useful here.  Need to be careful about it's use though,

$ kde-open --help-kde-tempfile
KDE-tempfile options:
  --tempfile    The files/URLs opened by the application will be deleted after use

Perhaps we could use some sort of heuristic like "if file is in $TMPDIR or /tmp, use --tempfile"...

Comment 5 Rex Dieter 2010-12-01 13:39:09 UTC
Filed bug upstream,

to help track this.

Comment 6 Rex Dieter 2010-12-01 13:40:56 UTC
Speaking of heuristics, perhaps we could assume that all calls from mailcap are on temp files?

Comment 7 Miroslav Lichvar 2010-12-01 13:52:03 UTC
Well, why not? :)

Is kde-open the only one which does this?

Comment 8 Rex Dieter 2010-12-01 14:05:58 UTC
I don't know, there are numerous backends that xdg-open can/does use.

Comment 9 Rex Dieter 2010-12-01 14:06:34 UTC
that said, kde-open is the only one with this behavior that I'm currently aware of.

Comment 10 Paul DeStefano 2011-07-22 20:00:02 UTC
Affects alpine, too.

For what it's worth, I think it is clearly xdg-open's responsibility to return either an error code or success after processing the input data.  That doesn't mean it has to wait until the chosen viewer is closed, but it can't quite before the back-end has *successfully* launched.  As it is, xdg-open returns success, even though the back-end fails immediately.

Comment 11 Ville Skyttä 2012-01-05 18:21:53 UTC
*** Bug 770782 has been marked as a duplicate of this bug. ***

Comment 12 Michal Jaegermann 2012-01-05 19:10:46 UTC
(In reply to comment #1)
> Hm, this looks like an xdg-open problem 

While tracking bug 770782 I tried with other "intermediary" shell scripts instead of xdg-open.  Consistently if I will append "; copiousoutput" to such mailcap entry then this works just fine; otherwise see above.  If a "handler" is called directly, say:

application/pdf; evince %s
image/*; display %s

then no problems and "; copiousoutput" is not required.

Comment 13 Rex Dieter 2012-01-05 19:24:20 UTC
I seem to no longer be able to reproduce this testing with kde-open, though gvfs-open still exhibits it.

fyi, Paul, xdg-open *does* wait for the backend to return and passes back the error code given by the helper.

My small test case script:

echo 'text!' > foo.txt
kde-open foo.txt
rm -v foo.txt

seems to work for me.  replace kde-open with gvfs-open and it fails (I think I have an upstream bug open, I'll try to dig it up).

anyone seeing this on KDE ?

Comment 14 Rex Dieter 2012-01-05 19:28:23 UTC
Here we go, bug #571932 , upstream 

Comment 15 Rex Dieter 2012-01-05 19:41:13 UTC
I'm not sure what appending '; copiousoutput' does in the context of mailcap, but if it works, our mailcap maintainers could consider tweaking it as such as a workaround to xdg-open backend bugs (like the aforemened gvfs-open).

Comment 16 Michal Jaegermann 2012-01-05 21:27:20 UTC
(In reply to comment #15)
> I'm not sure what appending '; copiousoutput' does in the context of mailcap,

That what mutt docs have to say (plus a bit more) on the subject:

          This flag tells Mutt that the command passes possibly large
          amounts of text on standard output. This causes Mutt to invoke a
          pager (either the internal pager or the external pager defined
          by the pager variable) on the output of the view command.
          Without this flag, Mutt assumes that the command is interactive.

> but if it works, our mailcap maintainers could consider tweaking it as such as
> a workaround to xdg-open backend bugs (like the aforemened gvfs-open).

It did work for me in all cases I tried even if there was no output.  It looks to  me that this "fix" is a side-effect of forcing mutt to wait.  The keyword seems to be "possbily". If this will have any effect on alpine, which somebody mentioned is affected too, I really have no idea.

Comment 17 Alain D D Williams 2012-11-08 17:04:58 UTC
For what it is worth - how my solution does not always work.... so not the real fix.

I changed my .mailcap to put a 3 second delay after starting evince. This allows me to see/read the PDF ... 3 seconds is long enough for evince to get going. But if I try to print it I get empty pages - to print I need to save the attachment to a file and then view with evince. I assume that the print function involves reopening the file somewhere.

Probably similar issues with other attachment types.

Comment 18 Gris Ge 2012-11-09 02:05:00 UTC
I am using a very ugly hack but a valid workaround by pointing mutt MIME to a script called mutt-open like below.
(you can change kde-open to xdg-open)

NEWFILE=/tmp/mutt_bak_`basename $1`
rm ${NEWFILE} -f
cp $1 ${NEWFILE} 1>/dev/null 2>&1
kde-open ${NEWFILE}

It just copy the file and open the new one.

I tried hard link, but still even hard link created, the both hard link and file vanish.

Comment 19 Suvayu 2013-09-19 12:45:57 UTC
This also affects XFCE.  exo-open also returns, like gvfs-open, before
the child application is done.  On the other hand, the open_generic
option inside xdg-open does work.

Since the bugs in gvfs-open, exo-open, etc have been open for over 3
years, I would request an xdg-open work around flag.  xdg-open could
accept an option like --use-generic.  This could skip the desktop
environment check and call open_generic.  This will help many of the
affected terminal applications work around the issue.

FWIW, Emacs is also affected when calling xdg-open asynchronously.


If you will accept a patch, I can work on this.  Please let me know if
that is agreeable.

Comment 20 Rex Dieter 2013-09-19 13:41:59 UTC
Feature request denied, however I have an alternative suggested that can work just as well,

DE=generic xdg-open ...

should work like you want.

Comment 21 Rex Dieter 2013-09-19 13:43:38 UTC
Well, not *denied* denied, but I really don't want to add options to workaround someone else's bugs or lack of features when a workaround already exists.  Let me know if my suggestion is not workable or acceptable for whatever reason.

Comment 22 Suvayu 2013-09-19 14:17:06 UTC
I was not aware of this possibility.  This work around is much better
than new options.  Some background: I came across this issue when
users started complaining after Org mode (an Emacs major mode) started
using xdg-open.  I will discuss this work around with the devs there.

Thank you very much :).

Comment 23 Jim Haynes 2013-10-05 23:12:10 UTC
Since I'm not very smart, could you please explain how/where to apply the
workaround DE=generic xdg-open ...

Comment 24 Rex Dieter 2013-10-06 00:49:26 UTC
Jim, in this case, presumably to /etc/mailcap

Comment 25 Rex Dieter 2013-10-06 00:52:42 UTC
Or... according to 'man mailcap', you can add user-specific customizations to ~/.mailcap

Comment 26 Michal Jaegermann 2013-10-06 01:55:47 UTC
(In reply to Rex Dieter from comment #24)
> Jim, in this case, presumably to /etc/mailcap

If we are talking about mutt then, accordingly to mutt manual, mailcap is searched along mailcap_path and you can get its value by running
'mutt -nF /dev/null -Q mailcap_path'.  On Fedora this gives a default mailcap_path="~/.mailcap:/usr/share/mutt/mailcap:/etc/mailcap:/etc/mailcap:/usr/etc/mailcap:/usr/local/etc/mailcap".  So mutt specific but system-wide mailcap entries with workarounds may go into /usr/share/mutt/mailcap.

That, of course, is not doing anything for other breakage, like that one from a comment 19, and every such case has to be worked around separately.  As gnome-open remains now broken for many years then likely it will stay that way.

Comment 27 Jim Haynes 2013-10-06 02:27:09 UTC
OK, that seems to work for me too - I'm using alpine as the mail program,
and making that change to /etc/mailcap allows it to work as it should.

Comment 28 Evgeni Golov 2015-12-22 07:45:56 UTC
In 2015, this still affects me (and I am still using mutt ;))

Running Gnome3 on Fedora23, "XDG_CURRENT_DESKTOP" is set to "GNOME" and thus the code in xdg-open's detectDE() does not trigger when I set "DE". Instead setting X_C_D to X-Generic works fine for me:

  XDG_CURRENT_DESKTOP=X-Generic xdg-open …

one could also unset the var and then the DE one would win

  XDG_CURRENT_DESKTOP= DE=generic xdg-open …


Note You need to log in before you can comment on or make changes to this bug.