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

Bug #1640514 reported by Andrea Bernabei on 2016-11-09
110
This bug affects 20 people
Affects Status Importance Assigned to Milestone
Snappy
Undecided
Unassigned
snapd (Ubuntu)
Undecided
Unassigned
Xenial
Undecided
Unassigned
Bionic
Undecided
Unassigned
zsh (Ubuntu)
Undecided
Unassigned
Xenial
Undecided
Unassigned
Bionic
Undecided
Unassigned

Bug Description

--- 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) wrote :

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

Andrea Bernabei (faenil) wrote :

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) wrote :

@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) wrote :

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) wrote :

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

Axel Beckert (xtaran) wrote :

@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) wrote :

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

Changed in snapd (Ubuntu):
status: New → Confirmed
Changed in zsh (Ubuntu):
status: New → Confirmed
Andrea Bernabei (faenil) wrote :

@xtaran: thanks for the useful info!

Michael Vogt (mvo) wrote :

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.

Michael Vogt (mvo) wrote :
tags: added: patch
Anders Sveen (anders-4) wrote :

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) wrote :

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) wrote :

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) wrote :

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.

Changed in snapd (Ubuntu Bionic):
status: New → Fix Released
Changed in zsh (Ubuntu Xenial):
status: New → Invalid
Changed in zsh (Ubuntu Bionic):
status: New → Invalid
Changed in zsh (Ubuntu):
status: Confirmed → Invalid
Zygmunt Krynicki (zyga) wrote :

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

Changed in snapd (Ubuntu Xenial):
status: New → Confirmed
Changed in snappy:
status: New → Fix Released
gustav (gustavs) wrote :

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) wrote :

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) wrote :

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) wrote :

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.

Vincent (enzopr) on 2019-08-29
Changed in snapd (Ubuntu):
status: Confirmed → New
Launchpad Janitor (janitor) wrote :

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

Changed in snapd (Ubuntu):
status: New → Confirmed
Changed in snapd (Ubuntu Bionic):
assignee: nobody → laurent le toudic (lolo645645)
Jazz (iguanamiyagi) wrote :

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) wrote :

I can confirm the observations of #19 for Ubuntu 19.10

Jimmy Merrild Krag (beruic) wrote :

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) wrote :

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) wrote :

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) wrote :

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.

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) wrote :

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

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.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers