Gnome Shell + Wayland + Run command , how can I set or change PATH?

Desktop
1

I am trying to “change my habits” i.e. migrate to Wayland based Gnome,
and not enjoying it. The current issue is that I cannot run my personal
hacks which live in ~/.local/bin (also known as ~/bin) from
the Run Command dialog. When I try it just says “Command not found”, so
it seems these directories are not in the ambient PATH, and I don’t know
how to set or change it. With X11 based Gnome I just had a setting in
.profile and it worked.

Referencing the following:

(yes I know it is obsolete) I tried creating a file
~/.config/environment.d/99-path.conf adding to the PATH, but it didn’t
help. Can you kindly point me to the right way?

2

What is in those scripts and what do you want to do?

3

One way to check is open a terminal, run journalctl -f to follow the journal then Alt+F2 and run printenv PATH. That prints the paths the Run command dialog uses to the journal.

Looks like maybe only paths from /etc/profile and /etc/profile.d/ are in it? You could try adding a localbin.sh file in /etc/profile.d/ with this in it:

if [ -n "$HOME" ] && [ -d "$HOME/.local/bin" ]; then
  append_path "$HOME/.local/bin"
fi

Log out and back in, see if that made a difference.

In the default path the Run dialog uses I see the /usr/local/bin directory. When I copy a executable script to that directory, I can run it from the Run command dialog. Mind the script runs without a terminal. So the output of the script is sent to the journal. If you want the command to run on a terminal you’ll have to write the script to open its own terminal.

The code is confusing me as js/ui/runDialog.js · main · GNOME / gnome-shell · GitLab I think says Ctrl+Enter should run the typed command in a terminal but when I try that with a script it opens the script in Text Editor and when I try it with a binary it says “command not found”.

4

I’m running on Fedora in case that makes a difference ..

You should be able to double check the path with:

strings /proc/$(systemctl show --user -p MainPID --value org.gnome.Shell@user.service)/environ | grep PATH

I tested with:

~/.config/environment.d/99-path.conf

containing


PATH=${HOME}/test-bin:$PATH

I did have to log out and back in for it to take.

5

@jakedane : thanks for showing me a way to debug this, at least.

I did this on my (Debian trixie) system and the output is

/usr/local/bin:/usr/bin:/bin

That looks like something compiled in, not run time configured;
and in particular, it’s nothing like what is already set
in the /etc/profile as shipped with the distro, which is much
richer. Not really surprising, because Gnome Shell is not a shell :stuck_out_tongue:

My scripts are quite specific to me, so I’d rather not put them
in /usr/local.

6

@tragivictoria : they are quick things I want to do in the UI,
and to not have to open a terminal window for.

As a first example: I am writing this reply in my preferred editor.
I have a short script to start an instance of the editor in the
right context, which will then in turn make it easy to copy the
text back into the web widget.

As a second example: almost always, I want to start my favorite
terminal (alacritty) with a particular window title. Not for display,
but for later searching. I do this by running a short script with
the title as the only argument.

If I should hazard a generalization, they are things that would
be a good fit for a custom keyboard shortcut … except there are
far too many to fit into that restricted namespace.

7

“Solved”. The culprit is this code near the top of /usr/bin/gnome-session:

if [ "x$XDG_SESSION_TYPE" = "xwayland" ] &&
   [ "x$XDG_SESSION_CLASS" != "xgreeter" ] &&
   [  -n "$SHELL" ] &&
   grep -q "$SHELL" /etc/shells &&
   ! (echo "$SHELL" | grep -q "false") &&
   ! (echo "$SHELL" | grep -q "nologin"); then
  if [ "$1" != '-l' ]; then
    exec bash -c "exec -l '$SHELL' -c '$0 -l $*'"
  else
    shift
  fi
fi

This already seems overengineered on its own to me, but in combination with the
absurdly complex rules for bash startup, it leads to the following misbehavior.
Let’s assume both ~/.profile and ~/.bash_profile exist and are independent
of each other, i.e. neither is a symlink to the other or sources the other or
executes the other. Then:

  • under X11, .profile gets sourced but not .bash_profile

  • under wayland, .profile does not get sourced, but .bash_profile does
    (and consequently, so does .bashrc if it is somehow invoked from .bash_profile,
    as is customary in Debian and maybe in other distros too).

I had a hardcoded PATH in my .bashrc because it never occurred to me that Gnome
might somehow explicitly invoke bash in the session startup.

My workaround has these pieces:

  • in .bashrc, I added ~/.local/bin to the hardcoded PATH

  • in .bash_profile, I condition the sourcing of .bashrc on the shell actually
    being bash, via BASH_VERSION

  • I make .profile just a stub to source .bash_profile.