gvfs-open is (still) preferred on mate, mate-open is kept only as a compatibility fallback.

(In reply to Rex Dieter from comment #1)
> gvfs-open is (still) preferred on mate, mate-open is kept only as a
> compatibility fallback.

Yes, but we have no command /usr/bin/mate-open anymore.

Yes, I know that.

I'm saying it (xdg-open) should never get that far, because it'll use gvfs-open instead (if it exists, which it should)

See comment#0
Apparently some Steam Python game manages to bypass or game/Python 2.7 glitch(?) through the check mechanism and ended up at mate-open.

Back to the report, what I am going to report here is that

it is time to change the "obsolete" mate-open to another fallback alternative.

and

NOT to argue why is the check mechanism is not working or why the game is not properly configured.

What's the point of still having a "non-existing" command in xdg-open as compatibility?

Can't we just follow LXDE (non-gnome example) using open_generic as fallback?

We certainly can add a fallback to use generic methods

But imo, it'll only be a bandaid for a gaping wound: any mate environment that doesn't include gvfs-open is going to have a degraded experience no matter what we do here to mitigate it.

adjusting summary

http://cgit.freedesktop.org/xdg/xdg-utils/commit/?id=abd6cef36874f73c5c1c4a734d83eba9d340afe4

Please let us know if you need anything else.

Ok thanks!

I guess it's Steam improper configuration all along after doing some further test...
(will report that later after I contacted the game developer)

I guess I can also rationalize your stand to keep mate-open for older MATE DE versions...
(but sooner or later have to drop it altogether though and even then I don't think old version of distro will ship this update)

But mind if I ask why is it

+ elif mate-open --help >/dev/null 2>&1; then

and not

+ elif mate-open --help 2>/dev/null 1>&2; then

like how the other *-open commands used?

Good catch.

Prior to my latest commit, xdg-open had an inconsistent hodge-podge:

$ grep null xdg-open.in 
    if gvfs-open --help >/dev/null 2>&1; then
    if gvfs-open --help >/dev/null 2>&1; then
    elif gnome-open --help >/dev/null 2>&1; then
    if gvfs-open --help 2>/dev/null 1>&2; then
        command_exec=`which $command 2>/dev/null`
        if which run-mailcap 2>/dev/null 1>&2; then
        if has_display && mimeopen -v 2>/dev/null 1>&2; then

I suppose we can standardize on the 2>/dev/null 1>&2 variant, sure (fixed in followup commit)