Bug 106161

As lxde is gtk-based, I don't think it makes sense to use pcmanfm-qt there.

I'll fix things to try pcmanfm first only if it exists, and fallback to open_generic method otherwise

https://cgit.freedesktop.org/xdg/xdg-utils/commit/?id=9cb017ae0eaa80c595445e083b2ea7c58569bf12

This is completely broken, the if construct does not automatically invoke the test builtin so you're checking to see if this commandline exits successfully:

`pcmanfm --help -a is_file_url_or_path "$1"`

pcmanfm doesn't know what the -a option is, but it ignores it once it sees --help.

See e.g. https://bugs.archlinux.org/task/58707

You should use:

`if command -v pcmanfm >/dev/null && is_file_url_or_path "$1"; then`

Thanks, not sure what I was thinking there.

Will fix asap

*** Bug 106636 has been marked as a duplicate of this bug. ***

I'm having trouble reproducing the problem you describe.

These code snippets work as expected for me (testing with both bash and dash):

if fake_command --help >/dev/null 2>&1 -a /bin/true; then echo yes ; fi
(returns nothing)

if pcmanfm --help >/dev/null 2>&1 -a /bin/true; then echo yes ; fi
(returns yes)


I am willing to change it though if you can provide a reproducible test case and which shell(s) for testing purposes.

Was unfamiliar with 'command -v', read up on
https://stackoverflow.com/questions/592620/check-if-a-program-exists-from-a-bash-script

which suggests it is a best-practice, so I think I will go with that option (once I test it's portable)

The problem is when fake_command is exists but second options is _false_.
That's the case.
[kreon@xaron ~]$ if /bin/false ; then echo "false=true"; fi

[kreon@xaron ~]$ if pcmanfm --help 2>&1 > /dev/null -a /bin/false ; then echo "false=true"; fi
false=true

JFYI: -a IS NOT theaten as AND until you use [] or [[]]
it's theaten as a ARGUMENT to pcmanfm.

*** Bug 106636 has been marked as a duplicate of this bug. ***

Opted for simplest fix
https://cgit.freedesktop.org/xdg/xdg-utils/commit/?id=31525d3855f876ddf2e29091b2e8d376f923e09e

May consider switching to using 'command -v' style checks in the future

Just FYI, IMHO in general it's useful to look at what's actually happening with:

```
$ systemd-nspawn /path/to/pcmanfm-chroot
[root@eschwartz ~]# set -x
++ printf '\033]0;%s@%s:%s\007' root eschwartz '~'
[root@eschwartz ~]# if pcmanfm --help >/dev/null 2>&1 -a /bin/true; then echo yes ; fi
+ pcmanfm --help -a /bin/true
+ echo yes
yes
++ printf '\033]0;%s@%s:%s\007' root eschwartz '~'
```

Notice how the "+ command"s that the shell (bash in this case) are actually running, are:

```
pcmanfm --help -a /bin/true
```

then

```
echo yes
```

Testing for failure instead of success is slightly more obvious:

```
[root@eschwartz ~]# if pcmanfm --help >/dev/null 2>&1 -a /bin/false; then echo yes ; fi
+ pcmanfm --help -a /bin/false
+ echo yes
yes
++ printf '\033]0;%s@%s:%s\007' root eschwartz '~'
```

And this works as expected:

```
[root@eschwartz ~]# if pcmanfm --help >/dev/null 2>&1 && /bin/true; then echo yes ; fi
+ pcmanfm --help
+ /bin/true
+ echo yes
yes
++ printf '\033]0;%s@%s:%s\007' root eschwartz '~'
[root@eschwartz ~]# if pcmanfm --help >/dev/null 2>&1 && /bin/false; then echo yes ; fi
+ pcmanfm --help
+ /bin/false
++ printf '\033]0;%s@%s:%s\007' root eschwartz '~'
```

Thanks, good advice

Since you ask.... Regarding the portability of command -v, it's optional -- "On systems supporting the User Portability Utilities option" -- for POSIX 2004 (SUSv3), but mandatory in POSIX 2008 (SUSv4).

If your shell is bash, dash, or busybox ash, it's most definitely confirmed supported. :)

If your shell is something that does not support the decade-old POSIX standard, but only supports the decade-and-a-half-old POSIX standard, then you might run into portability standards. Do you have a target userbase for xdg-utils that uses some other shell which does not support POSIX 2008? If so, then there's absolutely no way to do this portably at all. You could use the external tool "which", but that isn't portable either (most Linux systems "probably" have it, but it sure isn't in any version of POSIX), in addition to being inefficient.

If you restrict yourself to Debian systems... well, Debian "solved" this by declaring "which" to be an essential piece of software for Debian operating systems, then decided to provide a SUSv3 shell in their repositories just to prove they can. I'm pretty sure no one actually uses it though, even the package description suggests it's a bad idea...

I'm unaware of any other shell provided as /bin/sh on Linux systems in general, which does not support this. IMHO it's madness to program for 15-year-old POSIX standards and get broken things, when you can program for 10-year-old standards instead, and get working things.

*** Bug 106564 has been marked as a duplicate of this bug. ***