evince thinks colon in filename means url syntax

[to be removed]

Binary package hint: evince

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".

[Pedro Villavicencio (pedro)]

Thanks for the report, 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.

[to be removed (liw)]

I would've answered this earlier, but launchpad either never sent me an e-mail about this, or it never reached me.

I can open files with similar names without problems in less, vi, and emacs. Gedit has the same problem as evince.

[Michael Rooney (mrooney)]

Hi Lars. I notice the title says trouble with escaped shell characters, but as Pedro mentioned, you aren't actually escaping them, unless by escaping you are referring to the quotes around just part of the filename. I have never seen a partially quoted filename but perhaps it is valid. If this is the case can you try escaping the colon with a backslash, otherwise if the single quotes are part of the filename, try Pedro's solution, and report back? Thanks!

[to be removed (liw)]

Mike,

you're right, I did not escape the colon in a way that changes what the program gets. I just tried that, it doesn't matter.

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.

(I'm also having a hard time seeing why this bug is incomplete, fixing that...)

[to be removed (liw)]

changing from incomplete to new since I can't see any missing information (before changing back to incomplete, please try to reproduce it first)

[Dimitrios Symeonidis (azimout)]

confirmed

i renamed an existing pdf file to foo:bar.pdf and typed evince foo\:bar.pdf in a terminal.
evince opened with an error message "the specified location is not supported"
however, double-clicking the same foo:bar.pdf in nautilus opens it in evince without a problem...

[GiuseppeVerde (launchpad-digitasaru)]

I helped chase down a similar bug earlier in gnumeric a year or two ago. The problem there was that the colon was causing the url identifier to believe that the file is a url of "<pathuptocolon>:<stuffaftercolon".

The same is the case here. forcing a file:// url works regarless of colon. The bug is triggered on colon, and that's what I searched for.

So the workaround is to use the file:// url syntax, and the solution is for someone to reach in to evince and fix the horkage. This might be in gvfs's command-line parser; I don't know and don't have time to fish around to find the fix (I have to leave town in 4 days and I must have my dissertation defence scheduled by then, which requires having the dissertation done)

[Pedro Villavicencio (pedro)]

Thanks for your bug report. This bug has been reported to the developers of the software. You can track it and make comments here: http://bugzilla.gnome.org/show_bug.cgi?id=589168

[Pedro Villavicencio (pedro)]

according to the glib maintainers this is not a bug:

"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.
"

[to be removed (liw)]

foo:bar.pdf is a relative path, so I conclude the upstream glib maintainers are wrong about this, assuming this still happens on karmic (I don't have access to my karmic machine right now to test).

[Pedro Villavicencio (pedro)]

Lars, may you comment upstream since you know better about this issue? Thanks in advance.

[Timmy Shih Jun Yee (shijun)]

Anyone following this bug may be interested in this:
https://bugzilla.gnome.org/show_bug.cgi?id=374341