$HOME/.local/bin not set (elogind/cosmic)

[PepperGray]

I'm running cosmic, elogind and openrc and $HOME/.local/bin is not added to my $PATH. That should be set automatically according to this spec: https://wiki.gentoo.org/wiki/XDG/Base_Directories

Code: Select all

$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/bin:/opt/bin:/usr/lib/llvm/21/bin:/usr/lib/llvm/20/bin:/usr/lib/llvm/19/bin

I'm not sure if this missing in some component, or I'm supposed to script it myself. I'm lunching cosmic like so:

Code: Select all

$ cat /etc/greetd/config.toml
[terminal]
vt = 7

# The default session, also known as the greeter.
[default_session]
command = "/usr/local/bin/start-cosmic"
user = "cosmic-greeter"

Code: Select all

$ cat /usr/local/bin/start-cosmic
#!/bin/sh
export XDG_SESSION_TYPE=wayland
export XDG_CURRENT_DESKTOP=COSMIC
export XDG_SESSION_TYPE=tty

exec /usr/bin/dbus-run-session /usr/bin/cosmic-comp /usr/bin/cosmic-greeter 2>&1 | /usr/bin/logger -t cosmic-greeter

I think this is either a code or a documentation bug, but I'm unsure at which point the PATH variable is supposed to be changed. Anyway I'd like to fix it and document it somwhere. Please help (:

[Hu]

What in that page led you to think that ~/.local/bin would be added to your $PATH automatically? The page makes no mention of PATH. It does say that systemd / elogind will set up the XDG_* variables, but PATH is not an XDG variable. The underlying specification notes, in part:

Distributions should ensure this directory shows up in the UNIX $PATH environment variable, at an appropriate place.

I interpret that to mean that systemd / elogind are not accepting responsibility for adjusting PATH, but instead delegating it to the distribution.

[PepperGray]

Thanks for the clarification! What is the proper place then to include $HOME/.local/bin in $PATH? I want to configure it for all users.

[RumpletonBongworth]

Thanks for the clarification! What is the proper place then to include $HOME/.local/bin in $PATH? I want to configure it for all users.

The answer depends on whether you want PATH to be duly affected for all processes launched by the user as a part of their session, or only for their choice of login shell. If the latter approach is acceptable, an /etc/profile.d drop-in will work for bash and most other sh(1) implementations.

Code: Select all

# /etc/profile.d/99-local-bin.sh

case :$PATH: in
        *:"$HOME"/.local/bin:*)
                ;;
        *)
                export PATH=$PATH:$HOME/.local/bin
esac

For this to affect a graphical terminal emulator, it must be configured to launch the shell as a login shell. Should that prove to be a nuisance, and if all of your users are going to be using bash, you may place the drop-in under /etc/bash/bashrc.d instead.

If it is the former approach that you wish for then you may as well incorporate that code into your start-cosmic script instead.

[RumpletonBongworth]

Actually, having considered what purpose the start-cosmic script serves, I don't suppose it will work there. I don't feel like disrupting my current operating environment to experiment with cosmic at present but pam_env.conf(5) might be another option, given that it supports @{HOME} expansion.

[b11n]

If I'm not mistaken, /etc/env.d could be used for this?

[RumpletonBongworth]

If I'm not mistaken, /etc/env.d could be used for this?

I'm afraid not. To understand why, one must consider the dubious way in which Gentoo integrates this directory. It does all three of the following things:

1. ships a specialised python script to generate /etc/profile.env from /etc/profile.d (env-update; not a shell)
2. sources /etc/profile.env from /etc/profile (in the hope that it constitutes safe and proper shell code ...)
3. incorporates /etc/profile.env from /etc/pam.d/system-login (not a shell; doesn't behave like a shell)

As concerns #1, env-update won't expand $HOME, so the idea is immediately dead in the water. But, for argument's sake, let's say that it could. What purpose would it serve to expand the value of $HOME that is effective for the user that last ran env-update? The answer is none; it simply wouldn't address the use-case.

[RumpletonBongworth]

I forgot to say also that #2 and #3 constitute an obvious impedance mismatch. You might be able to inject an env.d snippet that env-update treats literally, in which case it will work for the case that a login shell is sourcing /etc/profile. Yet, the mechanism described by #3 cannot work in the same way. Given that, one might as well just create an /etc/profile.d drop-in in the first place (and without the annoyance of having to re-generate the profile.env file).

[b11n]

Ah, of course, $HOME (or '~') is expanded before being placed in the env. Thanks for clueing me in.

I did a little test though by escaping a tilde in my .bashrc and:

Code: Select all

export PATH="${PATH}:\~/.local/bin"

and it was effective. The PATH env var contains a literal tilde, which (bash, at least) expands when used instead. The shell being the shell of course, this itself probably brings a range of its own foot-guns I don't yet know about.

[RumpletonBongworth]

Ah, of course, $HOME (or '~') is expanded before being placed in the env. Thanks for clueing me in.

I did a little test though by escaping a tilde in my .bashrc and:

Code: Select all

export PATH="${PATH}:\~/.local/bin"

and it was effective.

It is defective.

Code: Select all

$ export PATH=/bin
$ PATH="${PATH}:\~/.local/bin"
$ type -a makeopus
bash: type: makeopus: not found
$ ls ~/.local/bin/makeopus
/home/rumpleton/.local/bin/makeopus

The PATH env var contains a literal tilde, which (bash, at least) expands when used instead. The shell being the shell of course, this itself probably brings a range of its own foot-guns I don't yet know about.

Tilde expansion can make for a truly splendid foot-gun. It only occurs under highly particular circumstances. Another - albeit of a lesser sort - is that of needlessly re-appending to PATH upon electing to re-source a shell program in which PATH was amended. That's why my initial example included a guard against it.

[b11n]

once again, I bow to your Unix-fu

[RumpletonBongworth]

Anyway, I might try the same setup that the OP has and explore some of the other options. Probably not before the week is through, though. I'm particularly interested in whether pam_env can handle it without outright replacing the prior value of PATH (I fear not).

[PepperGray]

I just checked how Arch, Ubuntu and Fedora do it and created a Bug report: https://bugs.gentoo.org/964354
I think it should be part of sys-apps/baselayout.

For now I use the approach from Arch: /etc/profile.d/home-local-bin.sh

Code: Select all

case ":${PATH}:" in
  *:"$HOME/.local/bin":*) ;;
  *) export PATH="$HOME/.local/bin:$PATH" ;; 
esac