GNOME Bugzilla – Bug 83994
gnomevfssrc parse "%20" of filename as ' '
Last modified: 2004-12-22 21:47:04 UTC
Package: GStreamer Severity: minor Version: 0.3.4 Synopsis: gnomevfssrc parse "%20" of filename as ' ' Bugzilla-Product: GStreamer Bugzilla-Component: gst-plugins Description: I have a file downloaded as name of "blah%20blah.mp3" and tried simple shell script to call gst-launch with gnomevfssrc. then, gst-launch complaint that there's no file of name "file://home/Keizi/blash blah.mp3" ------- Bug moved to this database by unknown@bugzilla.gnome.org 2002-06-03 13:57 ------- Unknown version unspecified in product GStreamer. Setting version to "0.3.3". Reassigning to the default owner of the component, gstreamer-maint@bugzilla.gnome.org.
gnomevfssrc expects a URI in the location field, not a file name. The right URI would be "blah%2520blah.mp3" in this case. Hope someone marks this NOTABUG now :)
why NOTABUG? local command line is not a URI. I think it'll be good to url-encode as well as 's/^/file:\/\/.../'.
Having to doubly-escape the URI is a bug. I'll look into this at some point. But gst-launch is a debug tool, not a user-friendly UI.
It's gst-launch's job to escape the URI if it uses gnomevfssrc, not the user. IMHO.
Created attachment 9009 [details] [review] correct way of handling "location" (NOT tested)
that patch actually looks pretty good, although I won't be able to get to it for a couple days. can you please test it out, xav? and of course, it's not gst-launch's job to do anything plugin-specific at all. i'll assume that was a typo ;)
Looks like the patch always escapes the given location: Only do this if constructing a URI from a filename; when 'location' starts as a URI, it is either already correctly escaped, or is invalid.
Created attachment 9295 [details] [review] This time it's tested. Please apply.
Patch applied, closing bug.