Description of problem: in open_generic func xdg-open calls check_input_file before opening an URL, but fails if the file cant be found. This is incorrect behavior, cause url should not be valid filename and exist on the filesystem. For example: file:///some_local_path/html/index.html#714.html is a correct URL (can can be opened by firefox just fine), but xdg-open fails to open it, with the error that file does not exist. xdg-open file:///some_local_path/html/index.html#714.html xdg-open: file '/some_local_path/html/index.html#714.html' does not exist Steps to Reproduce: 1. Login as normal user and start KDE for example. 2. open X terminal and become root (su -). DE will be set to generic in this case and xdg-open will call open_generic function by default. 3. Try to open valid URL that doesn't coincide with filename on filesystem. Additional info: If I comment check_input_file call in open_generic() function in xdg-open, everything works just fine :)
i think this bug is the closest to the way xdg-open is broken for me on gentoo + awesome wm, i.e. i also fall back to open_generic: $ xdg-open 'http://www.google.com' + check_common_commands http://www.google.com + '[' 1 -gt 0 ']' + parm=http://www.google.com + shift + case "$parm" in + '[' 0 -gt 0 ']' + '[' -z '' ']' + unset XDG_UTILS_DEBUG_LEVEL + '[' 0 -lt 1 ']' + xdg_redirect_output=' > /dev/null 2> /dev/null' + '[' xhttp://www.google.com '!=' x ']' + url= + '[' 1 -gt 0 ']' + parm=http://www.google.com + shift + case "$parm" in + '[' -n '' ']' + url=http://www.google.com + '[' 0 -gt 0 ']' + '[' -z http://www.google.com ']' + detectDE + '[' x = xtrue ']' + '[' x '!=' x ']' ++ dbus-send --print-reply --dest=org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.GetNameOwner string:org.gnome.SessionManager + xprop -root _DT_SAVE_MODE + grep ' = \"xfce4\"$' + '[' x == xLXDE ']' + DE= + '[' x = x ']' + DE=generic + '[' x/usr/bin/firefox-bin = x ']' + case "$DE" in + open_generic http://www.google.com + echo http://www.google.com + grep -q '^file://' + echo http://www.google.com + egrep -q '^[a-zA-Z+\.\-]+:' + local file=http://www.google.com + echo http://www.google.com + grep -q '^file:///' + check_input_file http://www.google.com + '[' '!' -e http://www.google.com ']' + exit_failure_file_missing 'file '\''http://www.google.com'\'' does not exist' + '[' 1 -gt 0 ']' + echo 'xdg-open: file '\''http://www.google.com'\'' does not exist' xdg-open: file 'http://www.google.com' does not exist + exit 2
Created attachment 50655 [details] [review] 0001-fix-xdg-open-open_generic-mistakenly-processes-every.patch patch e-mailed to Rex
apologies, while above patch makes things apparently work, it's not a proper fix. afaics 415 # Paths or file:// URLs 416 if (echo "$1" | grep -q '^file://' || 417 ! echo "$1" | egrep -q '^[a-zA-Z+\.\-]+:'); then should not succeed for http URLs, but it does. [a-zA-Z] matching always creates locale problems.
Created attachment 50658 [details] [review] 0001-fix-xdg-open-open_generic-mistakenly-processes-every.patch proper fix. replaces locale-dangerous [a-zA-Z+] with [[:alpha:]+].
You sent me a different patch via mail that moves the check_input_file "$file" for only file:/// case. Which of these I be applying (or both)?
ah, cluing myself in, seems only this latest patch should be considered. ok :) In the future, please patch .in files instead of the preprocessed scripts themselves, thanks.
http://cgit.freedesktop.org/xdg/xdg-utils/commit/?id=9a5895b1f14829c971ec406a3da3cd971e0529c7 Thanks!
ah, of course, didn't even notice the .in files. usually executables themselves aren't part of the src clone.
Yeah, that's a separate issue of getting my fellow maintainer(s) to agree to remove those processed files from scm (you know which side of the issue I'm on... :) )
on related note, how about the output of: git grep a-z i think it's safe to say there's plenty more of these issue gems hidden waiting to pop up.
*** Bug 92440 has been marked as a duplicate of this bug. ***
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.