I am trying each day to improve the liferea snap
When the snap is not confined, I can open links in my default browser, but with strict confinement it fails. I found that the problem is that it uses x-www-browser
(the default browser in debian systems). I used a shell in the snap and see that there is no such command. So, I thought to use the xdg-open
command instead. But it fails again. If I use it from the a shell inside the snap it fails quietly .
alejo @ ~ - [] $ snap run --shell liferea
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.
alejo@steven:/home/alejo$ xdg-open https://www.google.com
alejo@steven:/home/alejo$
I found in the forums a lot of people with similar problems. So… I am missing something here? Is some config needed to use the xdg-open command?
Thanks
The xdg-open
inside the sandbox just performs a D-Bus call to a process outside the sandbox, asking it to open the URL (using the xdg-open
found outside of confinement). If that command returned an error, you should have seen that reported in the sandbox.
Does running xdg open https://www.google.com
outside of the snap sandbox work correctly?
It workds outside the sandbox but fails inside. This is an example
alejo @ ~ - [] $ xdg-open https://www.google.com
alejo @ ~ - [] $ snap run --shell liferea
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.
alejo@steven:/home/alejo$ xdg-open https://www.google.com
alejo@steven:/home/alejo$
The first call to xdg-open works. It opened a tab with google
The second call did nothing.
This is even weirder. I have other snap, bastet (https://github.com/almejo/bastet-snap). Inside that snap xdg-open
doesnt work either becouse it says.
alejo @ ~ - [] $ snap run --shell bastet
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.
alejo@steven:/home/alejo$ xdg-open https://google.com
bash: /usr/bin/xdg-open: Permission denied
Both snaps use strict confinement, so maybe some plug?
You must plugs ‘desktop’ to use xdg-open. If after doing that your problem is still not solved, be sure that your snap is not shipping xdg-open from stage-packages and accidentally using it (eg, find /snap/yoursnap/current/ -name xdg-open
should come back empty. If it doesn’t, you should either remove it (eg, using ‘stage’ in snapcraft.yaml; this is the easiest option), ensure that the PATH is setup so that /usr/bin is before $SNAP/usr/bin (or wherever xdg-open is)) or if using layouts, that the layout isn’t redirecting /usr/bin/xdg-open to something in your snap/putting something in your snap before /usr/bin/xdg-open in your PATH.
The snap has the desktop
plug, but also has the desktop-legacy
. Can be that a problem?
The problem persists. I have not included xdg-open
$ find /snap/liferea/ -name xdg-open
$
Also, this is the content of xdg-open
inside the snap
alejo @ ~/mysnaps/liferea-snap - [master] $ snap run --shell liferea
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.
alejo@steven:/home/alejo/mysnaps/liferea-snap$ which xdg-open
/usr/bin/xdg-open
alejo@steven:/home/alejo/mysnaps/liferea-snap$ cat /usr/bin/xdg-open
#!/bin/sh
exec snapctl user-open "$@"
alejo@steven:/home/alejo/mysnaps/liferea-snap$
For what it is worth, when I installed your liferea snap from the edge channel, xdg-open
seemed to run fine from the snap run --shell liferea
shell.
Is there anything unusual about your system? What desktop environment and distribution are you running?
![:expressionless: :expressionless:](https://forum.snapcraft.io/images/emoji/twitter/expressionless.png?v=12)
I run ubuntu 20.04 with gnome. I upgraded from 4.10 to 18.04 without stop, but for then I installed from scratch and then upgraded to 18.10, 19.04, 19.10.
I have not booted my machine in a couple of days. I will try that in a couple of hours (working now in other machine).
Is there a log to see something? Snappy.scan-logs shows nothing
I will try from a virtual machine for further information