1

I have just installed a brand new debian buster:

$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 10 (buster)
Release:    10
Codename:   buster
$ cat /etc/profile
 [..]
if [ "`id -u`" -eq 0 ]; then
  PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
else
  PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
fi
export PATH

[...]

$ whoami 
zozo
$ su 
Password:
# id -u 
0
# printenv | grep -i ^path 
PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

If I run as root:

  • # grep -i path /etc/profile.d/* no output
  • # grep -i path ~/.profile no output
  • # grep -i path ~/.bashrc no output

Being on a Debian system there is no ~/.bash_profile nor ~/.bash_login

vi ~/.profile 
PATH="/usr/bin:/bin:/usr/sbin:/sbin"

but the problem remains:

Ctrl+D to get back to normal user

then

$ su 
password:

printenv | grep -i ^path

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

So I made some searches: 6.2 Bash Startup Files

then

if [ -z "$PS1" ];then echo NOT interactive shell ;else echo INteractive shell ;fi
INteractive shell

it says:

When Bash is invoked as an interactive login shell, [...] it first reads and executes [...] /etc/profile [...]. After [...] it looks for [...] ~/.profile ...

So I am wondering why it does not load PATH from ~/.profile (~/.profile is not called/loaded). Of course, if I put it in ~/.bashrc, it works.

So, at the end, by default, no path for essential commands like shutdown or reboot.

Furthermore, I am realizing that tools like systemctl, which are by essence an administration commands are located in /usr/bin instead of /sbin or /usr/sbin (and many other admin commands, like getfacl, setfacl... but that's another problem).

I should have missed something here.

AdminBee
  • 22,803
achille
  • 203
  • What does echo $0 print? – schily Jun 24 '20 at 10:40
  • @schily: $0 prints 'bash' – achille Jun 24 '20 at 10:54
  • Then this is not a login shell and this is the reason. – schily Jun 24 '20 at 11:01
  • The one in your desktop environment's terminal emulator is most likely a non-login shell (which doesn't source ~/.profile). Usually, the display manager takes care of setting up the environment for each graphical user session. E.g. I see on a fresh buster VM that gdm3 (GNOME display manager) runs a login shell (and thus sources ~/.profile) to exec the GNOME Session Manager. Changes to ~/.profile require you to log out/in to be visible, but should also take effect immediately in a login shell (i.e. invoked as bash -l). (Cont...) – fra-san Jun 24 '20 at 22:08
  • (...Cont) If this is not the case, please also add the desktop environment, display manager and terminal emulator you are using to your question. – fra-san Jun 24 '20 at 22:09

1 Answers1

5

Only a login shell reads /etc/profile and ~/.profile.

You may check this by calling echo $0.

If the output starts with a minus sign (e.g. -bosh), this is a login shell.

So a good idea is to log out and log in again after you changed /etc/profile

Files like /etc/sh.shrc, /etc/bash.bashrc or their counterparts in $HOME are read by any interactive shell, not only by the login shell.

Since your shell is not a login shell, you should try to find out why this happens. If you log in via ssh or from a text console and your shell is not marked as a login shell, you definitely should make a bug report against your distro.

A correct X11 environment starts all shells in newly created shell windows with argv[0] beginning with - and for this reason, such shells identify themselves as login shell. If this does not happen for you, your X11 environment may be broken.

If you start a super-user session with su, this definitely does not start a login shell. If you like such a shell to behave like a login shell, call:

su -

Did you try that?

Jeff Schaller
  • 67,283
  • 35
  • 116
  • 255
schily
  • 19,173