Page MenuHomePhabricator

enlightenment_open does not support PDF files and throws a confusing error when a user tries
Closed, ResolvedPublic

Description

As reported in https://bugzilla.redhat.com/show_bug.cgi?id=1329804, the "xdg-open" command checks for the existence of enlightenment_open when the Window Manager is Enlightenment, and hands off requests to it. The user passed a PDF filename to xdg-open, which gets relayed to enlightenment_open, and the result is as follows:

[spot@localhost Documents]$ enlightenment_open calendar.pdf
Filename "file:///home/spot/Documents/calendar.pdf" does not exist or is not a regular file

To be clear, in this example, "calendar.pdf" exists and is a valid PDF file.

spotrh created this task.Apr 26 2016, 12:51 PM

I cannot reproduce here, enlightenment_open works with every combinations of paths I have tryied: relative paths, absolute ones, full urls...

Seems more info is needed, what version of enlightenment? what distro?

zmike triaged this task as Pending on user input priority.May 11 2016, 10:57 AM

Fedora 23 and 24. Enlightenment 0.20.7

I cannot find that error message in the source of enlightenment_open, so I suspect the error comes from the application that should open the pdf.
On my system pdf files are handled by evince, do you know the one on your distro? can you try opening it directly? ex:

evince file:///home/spot/Documents/calendar.pdf

and

evince /home/spot/Documents/calendar.pdf

This should help to understand where the problem is, maybe your pdf application do not support full uris?

I was confused as well, because I couldn't find that error in the source code either.

Opening it directly works fine with evince with both URI and full path, so that's not it.

hmmm, maybe the wrong command is begin executed instead of evince.

Did you build enlightenment yourself? can you try to add a printf line in e_open.c and rebuild?

something like:

printf("executing: '%s'\n", *itr);

just before the system() call at line 555

Okay, that did the trick. enlightenment_open is calling evince-previewer with a URI. When I look in the evince source code, I can see the error is coming from previewer/ev-previewer.c:

if (!g_file_test (argv[1], G_FILE_TEST_IS_REGULAR)) {

        g_printerr ("Filename \"%s\" does not exist or is not a regular file\n", argv[1]);
        return 1;
}

One possible fix would be to call evince rather than evince-previewer, but I think the correct fix is inside evince-previewer, it shouldn't choke on a valid file URI.

yep, evince-previewer fail also here with uris.

Indeed the bug is really in evince, but in my distro I never see that previewer, maybe it is not meant to be used in this way? It also have an old look (no csd like evince) that make me think it's old or deprecated.

So nothing to do with e itself, fix evince or fix the default application in your distro.

Can you please explain all this in the original ticket in redhat please?

So nothing to do with e itself, fix evince or fix the default application in your distro.

Note that the blog post mentioned by spotrh suggests some improvements in the way enlightenment_open handles this issue.