Bug 106161

Summary: /usr/bin/xdg-open: line 922: pcmanfm: command not found
Product: Portland Reporter: aversa
Component: xdg-utilsAssignee: Rex Dieter <rdieter>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: medium CC: edacval, ivan.agarkov
Version: unspecified   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
i915 platform: i915 features:

Description aversa 2018-04-20 20:45:38 UTC
xdg-utils-1.1.2 (with pcmanfm-qt-0.11.1) on slackware-current gives:

/usr/bin/xdg-open: line 922: pcmanfm: command not found

Built using:


<         pcmanfm "$file"
>         pcmanfm-qt "$file"
Comment 1 Rex Dieter 2018-05-10 14:34:26 UTC
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
Comment 3 Eli Schwartz 2018-05-23 22:03:15 UTC
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`
Comment 4 Rex Dieter 2018-05-23 22:06:23 UTC
Thanks, not sure what I was thinking there.

Will fix asap
Comment 5 Rex Dieter 2018-05-24 14:26:13 UTC
*** Bug 106636 has been marked as a duplicate of this bug. ***
Comment 6 Rex Dieter 2018-05-24 14:32:39 UTC
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.
Comment 7 Rex Dieter 2018-05-24 14:36:01 UTC
Was unfamiliar with 'command -v', read up on

which suggests it is a best-practice, so I think I will go with that option (once I test it's portable)
Comment 8 Ivan Agarkov 2018-05-24 18:16:14 UTC
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

JFYI: -a IS NOT theaten as AND until you use [] or [[]]
it's theaten as a ARGUMENT to pcmanfm.
Comment 9 Rex Dieter 2018-05-24 19:36:58 UTC
*** Bug 106636 has been marked as a duplicate of this bug. ***
Comment 10 Rex Dieter 2018-05-24 19:42:04 UTC
Opted for simplest fix

May consider switching to using 'command -v' style checks in the future
Comment 11 Eli Schwartz 2018-05-25 01:51:12 UTC
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
++ 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


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
++ 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
++ 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 '~'
Comment 12 Rex Dieter 2018-05-25 01:53:22 UTC
Thanks, good advice
Comment 13 Eli Schwartz 2018-05-25 02:14:25 UTC
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.
Comment 14 edacval 2018-06-07 10:01:04 UTC
*** Bug 106564 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.