I'd argue that's not a fair test,

what happens if you try:

xdg-open file://`pwd`/index.html#test

Interestingly,

$ DE="generic" XDG_CURRENT_DESKTOP="" xdg-open index.html#test
xdg-mime: file 'index.html#test' does not exist
xdg-mime: mimetype argument missing
Try 'xdg-mime --help' for more information.

but then it opens the file ok in firefox for me.


In KDE, I get an error:
The file or folder ".../index.html#test" does not exist.
(the same error as if I run by hand:
kde-open index.html#test
)

but as per my initial comment, Qt/KDE is picky about URIs, it insists you give a protocol (ie, file://)

Either way, there's still a problem with xdg-mime failing somewhere here, I'll see if I can find more what's going on there.

Same thing happens:

```
xdg-mime: file '/home/despairblue/index.html#test' does not exist
xdg-mime: mimetype argument missing
Try 'xdg-mime --help' for more information.
Could not determine mimetype for file: /home/despairblue/index.html#test
```

And then it just never exits :/

I'm not using any desktop environment, just i3.

I think this should help:

--- /usr/bin/xdg-open.orig      2015-04-06 07:39:33.572166692 -0500
+++ /usr/bin/xdg-open   2015-04-06 07:36:27.569417647 -0500
@@ -707,7 +707,7 @@
         file_check=${file_check%%\?*}
         check_input_file "$file_check"
 
-        open_generic_xdg_file_mime "$file"
+        open_generic_xdg_file_mime "$file_check"
 
         if which run-mailcap 2>/dev/null 1>&2; then
             run-mailcap --action=view "$file"


Can you verify ?

actually, that's the wrong fix, it needs to be fixed inside open_generic_xdg_file_mime

But, I'd like to know where the hang occurs for you, can you insert a:

set -x 

somewhere near the top of xdg-open, and re-run the test case?  I'd like to see the last few lines of output

OK, this should be a better fix (than comment #4):

diff -u /usr/bin/xdg-open.orig /usr/bin/xdg-open
--- /usr/bin/xdg-open.orig      2015-04-06 08:27:10.396932209 -0500
+++ /usr/bin/xdg-open   2015-04-06 08:29:31.534667495 -0500
@@ -706,7 +706,8 @@
         file_check=${file_check%%\?*}
         check_input_file "$file_check"
 
-        open_generic_xdg_file_mime "$file"
+        filetype=`xdg-mime query filetype "$file_check" | sed "s/;.*//"`
+        open_generic_xdg_mime "$file" "$filetype"
 
         if which run-mailcap 2>/dev/null 1>&2; then
             run-mailcap --action=view "$file"

Went ahead and committed the immediate fix,
http://cgit.freedesktop.org/xdg/xdg-utils/commit/?id=3e9a91b44d8d4639000fbe2b49ee303cd3f836e0

I'd still be interested in output per comment #5 if you don't mind (to help find out why xdg-open would not exit properly).

Sure, thanks, I'll try that out when I'm at home and will get back to you.

Here is the complete output: https://gist.github.com/despairblue/c95abf709787faa41bef

The problem seems to be that it starts lynx if I add an anchor. Without the anchor it starts google-chrome-stable.

Or maybe it tries to find out if lynx is installed by executing it. I'll have to take a closer look at xdg-open itself.

Ok the problem is that xdg-mime and mimeopen think that the anchor is part of the file name, thus they fail to return a mime type for it, so xdg-open goes through the list of known browsers and falls through to lynx. Which it then runs with eval.

1. I don't think lynx should be part of that list unless it's started with a new terminal emulator, otherwise it just opens and blocks xdg-open.
2. The list should be more exhaustive, if it'd contain chromium or google-chrome-stable it would work even on archlinux.
3. It might be better to use hash and exec instead of eval when going through the browser, like this:
```
for browser in $BROWSER; do
        if [ x"$browser" != x"" ]; then
            browser_with_arg=`printf "$browser" "$1" 2>/dev/null`
            if [ $? -ne 0 ]; then
                browser_with_arg=$browser;
            fi

            hash $browser 2>/dev/null
            if [ $? -ne 1 ]; then
                if [ x"$browser_with_arg" = x"$browser" ]; then
                    exec $browser "$1" #$xdg_redirect_output;
                else exec $browser_with_arg #$xdg_redirect_output;
                fi
            fi
        fi
    done
```
That way lynx could stay in the list and would work.

So, should I write a patch adding more known browsers, removing lynx, changing the for loop or do you see another solution?

regards

(In reply to Rex Dieter from comment #7)
> Went ahead and committed the immediate fix,
> http://cgit.freedesktop.org/xdg/xdg-utils/commit/
> ?id=3e9a91b44d8d4639000fbe2b49ee303cd3f836e0
> 
> I'd still be interested in output per comment #5 if you don't mind (to help
> find out why xdg-open would not exit properly).

Typo:

--- a/scripts/xdg-open.in
+++ b/scripts/xdg-open.in
@@ -276,7 +276,7 @@ open_generic()
         file_check=${file_check%%\?*}
         check_input_file "$file_check"
 
-        filetype=`xdg-mime query filetype "$filecheck" | sed "s/;.*//"`
+        filetype=`xdg-mime query filetype "$file_check" | sed "s/;.*//"`
         open_generic_xdg_mime "$file" "$filetype"
 
         if which run-mailcap 2>/dev/null 1>&2; then

Thanks, typo fixed.

As far as browser handling goes, my hope is that code path never gets reached.  I'm tempted to remove it (though probably will wait for 1.2 to do that).

In the meantime, if you have any simple, portable ways to make this better, I'd welcome it.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xdg/xdg-utils/issues/80.