GNOME Bugzilla – Bug 589168
evince thinks colon in filename means url syntax
Last modified: 2016-10-12 11:56:46 UTC
this report has been filed here: https://bugs.edge.launchpad.net/ubuntu/+source/evince/+bug/160996 "Evince does not seem to be able to open a file with a colon in the name: > liw@dorfl$ evince 'foo:bar'.pdf > > (evince:12543): libgnomevfs-CRITICAL **: gnome_vfs_uri_is_local: assertion `uri != NULL' failed This is probably due to some kind of assumption that the colon indicates a protocol in a URI scheme. It is highly surprising to the user, and if it can't be fixed (by seeing if a file with that name actually exists), at least the user should get a more sensible error message than "File not found"." "can you open a text file with similar name in vi, gedit, or emacs? it seems that you need to use something like \'foo\:bar\'.pdf, i really don't consider this an evince bug." "I can open files with similar names without problems in less, vi, and emacs. Gedit has the same problem as evince." "There are, of course, ways of entering the filename in a way that makes evince (or other GNOME) programs be able to open them. One can enter the path in a way to have a slash before the colon (./foo:bar.pdf) or even a file:// url. However, the documentation (manpage, --help) claims that evince accepts filenames and that is clearly wrong. Evince accepts more than just filenames, and some valid filenames are interepreted wrongly. This can be fixed via, for example, fixing the documentation to clearly say that the programs accept filenames or URLs. This, at least, would make it obvious to the user that the colon may be a problem." Thanks,
The gnome-vfs warning points to this not being a recent evince version; which one is it, exactly; and is this reproducible on 2.27.x ?
Yes, it's still reproducible with evince 2.27.4, it doesn't give any error on the command line but the evince window just says "Error opening file: No such file or directory"
hmm, I'd say it's gio issue. See what this test case does: file = g_file_new_for_commandline_arg (argv[1]); uri = g_file_get_uri (file); g_object_unref (file); g_print ("%s\n", uri); g_free (uri); $ ./test foo:bar.pdf foo:///bar.pdf
This is behaving pretty much as documented: The value of @arg can be either a URI, an absolute path or a relative path resolved relative to the current working directory.
Not quite, foo:bar.pdf is a valid relative path (as pedro pointed out) when used with other programs, why would it not be in evince?
I am the original bug reporter to Ubuntu. I agree with Bartek: 'foo:bar.pdf' is a valid Unix filename, and it would be appropriate for evince to accept is as such, if it accepts any filenames. This may well be (and probably is) a bug in some underlying library, though, so re-assigning the bug to the proper package would be good. For example, gedit has the same problem (touch foo:bar.txt; gedit foo:bar.txt). Fixing the underlying library would fix this for everyone. Mixing filename and URI syntax is always going to be wrought with problems, unfortunately.
(For what it's worth (because I came across this via evince too), this sounds similar to Bug #374341 ...)