/snap/bin is not added to the PATH when using zsh

[Andrea Bernabei]

--- Environment ---
Ubuntu Zesty 17.04 (dev)
zsh
snapd 2.16

--- Description ---
zsh does not seem to load the scripts in /etc/profile.d/ (see https://bugzilla.redhat.com/show_bug.cgi?id=88457 ).
As a consequence, /snap/bin is not added to PATH, and running snaps from terminal (without snap run) does not work

--- How to reproduce ---
1) Install zsh
2) try running apps provided by snaps from the shell, without using snap run

[Oliver Grawert (ogra)]

not really a snappy bug, is it ? zsh should be fixed ...

[Andrea Bernabei (faenil)]

the zsh bug I linked was marked as NOTABUG.
It seems zsh used to source /etc/profile, but that was changed at one point, to fix some other problem.

So "fixing" zsh does not seem like a viable option :/

[Axel Beckert (xtaran)]

@faenil: What you're citing is RedHat-specific and doesn't seem to related to any commit in the upstream or the Debian zsh git repository.

So this is basically a Debian-/Ubuntu-specific feature request for something that RedHat already kicked out again.

[Axel Beckert (xtaran)]

Additionally, /etc/profile.d/ in Debian/Ubuntu is a feature implemented in /etc/profile which is installed by base-files in its postinst script.

But zsh only loads /etc/profile if invoked in its sh or ksh emulation mode (which is not the case if invoked as "zsh"). I don't think that we should change that behaviour.

[Gustavo Niemeyer (niemeyer)]

Indeed. The right fix is probably a trivial change in /etc/zsh/zshenv.

[Axel Beckert (xtaran)]

@niemeyer: Nope, if you want the equivalent to /etc/profile, then use /etc/zsh/zprofile.

See https://tanguy.ortolo.eu/blog/article25/shrc why zshenv is not equivalent to profile.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Andrea Bernabei (faenil)]

@xtaran: thanks for the useful info!

[Michael Vogt (mvo)]

Looks like there is no zprofile.d directory (similar to profile.d) so there is nothing that snapd itself can hook into. This really needs to be fixed in zsh itself apparently.

[Anders Sveen (anders-4)]

This is still manifested on Ubuntu 17.10.

After some digging it seems later versions of Systemd supports a /etc/environment.d which works regardless of Bash/ZSH/Other shell. To me it seems any solution should use it.

I have posted a temp fix (also fixing desktop search) using environment.d for your user here: https://forum.snapcraft.io/t/desktop-snaps-do-not-appear-in-the-dash-menu-on-gnome-in-17-10-final-beta/2340/14

[Michael Vogt (mvo)]

I pushed https://github.com/snapcore/snapd/pull/5390 which should fix this with the next snapd release. It will drop in a systemd environment configuration file that adds /snap/bin.

[Zygmunt Krynicki (zyga)]

I just tested 2.35 build and I have /snap/bin at the end of my PATH. I'm using zsh in Ubuntu 18.04 for this experiment.

[Zygmunt Krynicki (zyga)]

Note that I was using Ubuntu 18.04 which is important. The older versions of Ubuntu don't have recent enough systemd to support environment.d injections.

[Zygmunt Krynicki (zyga)]

I marked the zsh part of this issue as invalid as we now have a way to inject environment into all the shells uniformly.

[gustav (gustavs)]

I am on 18.10. New installed not updated and when i Switch from bash to zsh snap stops working. when i switch back to bash snap apps works.

[Dolphy (dolphytr)]

it works me: https://forum.snapcraft.io/t/desktop-snaps-do-not-appear-in-the-dash-menu-on-gnome-in-17-10-final-beta/2340/13

mkdir -p ~/.config/environment.d
echo "PATH=$PATH:/snap/bin\nXDG_DATA_DIRS=\"${XDG_DATA_DIRS:-/usr/local/share:/usr/share}:/var/lib/snapd/desktop\"" > ~/.config/environment.d/60-snap-icons-and-bin.conf

[Michael Stucki (mstucki)]

The fix by @dolphytr works, but it's still incomplete. It helps to bring back apps to the menu, but they still can't be run from the command line. For this to work, I had to apply the commands from #18 plus add these two lines to my $HOME/.zshrc:

# Fix environment for Wayland + zsh + snapd
source /etc/profile.d/apps-bin-path.sh

As these are just workarounds, the root of the problem seems to be somewhere else:

The script in /etc/profile.d/apps-bin-path.sh takes care of all the neccessary changes. It is sourced when starting an X11 session but not when starting a Wayland session (at least not in combination with zsh).

I suggest to reopen this ticket until that's solved.

[James Henstridge (jamesh)]

I've put together a PR to set XDG_DATA_DIRS via environment.d, as was done for PATH:

https://github.com/snapcore/snapd/pull/6813

When this is merged and released, it should remove the need for any special user configuration.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Jazz (iguanamiyagi)]

I use bash and still face this issue. The fix proposed at #18 doesn't work entirely. You should add double quotes to the PATH and print the new line properly by replacing echo with printf:

mkdir -p ~/.config/environment.d
printf "PATH=\"$PATH:/snap/bin\"\nXDG_DATA_DIRS=\"${XDG_DATA_DIRS:-/usr/local/share:/usr/share}:/var/lib/snapd/desktop\"" > ~/.config/environment.d/60-snap-icons-and-bin.conf

[Jimmy Merrild Krag (beruic)]

I can confirm the observations of #19 for Ubuntu 19.10

[Jimmy Merrild Krag (beruic)]

I jumped the gun a bit. What I ment was to write that sourcing /etc/profile.d/apps-bin-path.sh fixes commands being available again. I have the following in my .zshrc:

if [ "$XDG_SESSION_TYPE" = "wayland" ] ; then

    ...other wayland fixes...

    # Fix environment for Wayland + zsh + snapd
    if [ -f "/etc/profile.d/apps-bin-path.sh" ] ; then
        source /etc/profile.d/apps-bin-path.sh
    fi

fi

[Jimmy Merrild Krag (beruic)]

The problem was not fixed with the above, as I discovered that of course it only fixes my terminal. Other applications (e.g. PyCharm) could not see the executables from snaps.

Creating ~/.pam_environment with the following content did the trick:

PATH DEFAULT=${PATH}:/snap/bin

[Jordan Williams (jwillikers)]

I have the same problem with snaps on Lubuntu. Snap packages would not show up in the launcher. Following the comment above: https://forum.snapcraft.io/t/desktop-snaps-do-not-appear-in-the-dash-menu-on-gnome-in-17-10-final-beta/2340/14 fixed this. It looks like FlatPak has already figured this out by adding paths to XDG_DATA_DIRS automatically. It is a bit concerning that this answer is from 2 years ago. Is some help needed to patch this?

[Jimmy Merrild Krag (beruic)]

It is strange. My XDG_DATA_DIRS has the value:

    /usr/local/share/:/usr/share/:/var/lib/snapd/desktop

, and I have never had issues with that.
Only the part added to PATH has bothered me.
Actually I have no idea where is gets this value from.

[Maciej Borzecki (maciek-borzecki)]

The environment is patched via a user session generator, which is applied automatically when user session starts. If anyone is still affected by this problem, please indicate your Ubuntu version as well as which desktop environment and login manager you use.

[Jordan Williams (jwillikers)]

I'm using Lubuntu 19.10 (lxqt, of course) with the default SDDM setup and I ran into this issue as described in #26.

[Maciej Borzecki (maciek-borzecki)]

The systemd way of inject environment does not fully address the problem. Simple `su -l <user> <command>` where the <user>'s shell is zsh is enough to demonstrate this. AFAICT this is also a problem with some desktop environments (non GNOME, or KDE), where the DE environment isn't updated for some reason.

From what I can tell, Fedora imports respective files from /etc/profile.d using ksh emulation. Arch imports the whole /etc/profile using sh emulation. Perhaps it's worth reconsidering.

[Nicolás Abel Carbone (nicocarbone)]

Having this problem in focal dev. When running the wayland session snapd apps don't appear in the gnome-shell menu. They do in X11.
Using zsh as default.

[Maciej Borzecki (maciek-borzecki)]

@nicocarbone on a running system, can you run `systemctl --user show-environment |grep XDG_DATA_DIRS` the output should include /var/lib/snapd/desktop.

Then find the PID of gnome-shell, and run `sudo strings /proc/<pid>/environ | grep XDG_DATA_DIRS`. The value should be identical to one you get from systemd.

[Nicolás Abel Carbone (nicocarbone)]

@maciek-borzechi: snapd does not appear in any of the two queries:

❯ systemctl --user show-environment |grep XDG_DATA_DIRS
XDG_DATA_DIRS=/home/nicolas/.local/share/flatpak/exports/share/:/var/lib/flatpak/exports/share/:/usr/local/share/:/usr/share/
❯ sudo strings /proc/2748/environ | grep XDG_DATA_DIRS
XDG_DATA_DIRS=/home/nicolas/.local/share/flatpak/exports/share/:/var/lib/flatpak/exports/share/:/usr/local/share/:/usr/share/

Any suggestions?

[Johannes Choo (jhanschoo)]

This still affects 19.10 eoan.

I hope a bug administrator can update the status to reflect that.

The push by vogt https://github.com/snapcore/snapd/pull/5390/files unfortunately does not work since by environment.d folder looks like this:

-rw-r--r-- 1 root root 106 Oct 30 20:17 990-snapd.conf
lrwxrwxrwx 1 root root 16 Feb 6 22:45 99-environment.conf -> /etc/environment

Notably, 99-envorinment.conf is executed after 990-snapd.conf since it is lexically later, and after 990-snapd.conf writes

PATH=$PATH:/snap/bin

we have 99-environment.conf overwriting

PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games"

it should be noted that 99-environment.conf is provided by the systemd package. I'll also raise a bug there about the naming of 99-environment.conf .

[Johannes Choo (jhanschoo)]

I partially retract my comment. The dash is lexicographically earlier. However, the fix pushed by vogt does not help with making "/snap/bin" available in zsh. I'll make a comment later if it turns out that these settings ought to have been be propagated to the environment in zsh from their current location but fail to.

[Johannes Choo (jhanschoo)]

bash from the tty receives the PATH with "/snap/bin" via sourcing "/etc/profile" (bash initialization file), and does not have it set before this. zsh from the tty does not receive the path, since it doesn't source "/etc/profile", and "/etc/zsh/zshenv", which it does source, does not update the PATH.

[Maye (michael-aye)]

Same problems here using Kubuntu 20.04 and fish shell. snap paths are missing in PATH and XDG vars.

[GigabiteLabs (gigabitelabs)]

For any current Zsh-converts suffering from this: I have the solution:

1) sudo edit your zprofile:

`sudo (vim, nano, vi) /etc/zsh/zprofile`

2) Add these two lines to the end of the profile to ensure Zsh is sourcing the ENV vars that lets wayland etc. find your snap apps:

```
emulate sh -c 'source /etc/profile.d/apps-bin-path.sh'
emulate sh -c 'source /etc/profile.d/flatpak.sh'

```

3) save the file & reboot your machine

Just used it and it worked perfectly, source: https://realjenius.com/2020/01/12/kde-neon-snap-apps-missing/

[Jakub Kuczys (jackenmen)]

This is still a problem on Ubuntu 22.04 (jammy). I'm experiencing this problem on Kubuntu 22.04 with the standard KDE + SDDM but I did not experience this issue when I installed (on that same Kubuntu) GNOME and switched my display manager to GDM3 while installing it. It seems that KDE + GDM3 also works while GNOME + SDDM does not.
It appears that SDDM doesn't currently import user session environment from systemd: https://github.com/sddm/sddm/issues/1276

PATH gets properly imported because snap uses a system environment generator (systemd.environment-generator). However, this environment generator only updates PATH, not XDG_DATA_DIRS. I'm not sure if system environment generator should alter XDG_DATA_DIRS (from my testing it seems that flatpak updates XDG_DATA_DIRS using both system and user environment generator) but snap could definitely use a user environment generator to do that.

The necessary code is pretty much already there because snap does have a system environment generator and user environment generator works in the exact same way. There might be some special handling needed for XDG_DATA_DIRS (since the environment.d/990-snapd.conf does `${XDG_DATA_DIRS:-/usr/local/share:/usr/share}` rather than just `$XDG_DATA_DIRS`) specifically but I imagine it probably wouldn't be too complicated.

Edit: also not an issue with LightDM