Ideas for why PATH has these directories

Question

In my .profile I have PATH="$HOME/.local/lib:$HOME/.local/bin:$HOME/.node_modules/bin:$HOME/.cargo/bin:$HOME/local/bin:/usr/bin:$PATH" In my .zshrc I have miniconda path stuff (export PATH="/home/user/miniconda3/bin:$PATH") but I removed that and it seems its the last that gets loaded and so I don't think thats the issue. However, in my shell, I get the following

/sbin:/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/opt/cuda/bin:/opt/cuda/nsight_compute:/opt/cuda/nsight_systems/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/var/lib/snapd/snap/bin

Maybe some arch packages set these paths? But what's setting sbin in my path? I'm not root.

Also my PATH command from .profile is not being picked up, I've tried it with and without export. I'm pretty sure it used to work. (EDIT: seems zsh only sources .zprofile)

Answer 1

The strange thing is the lib directory. Having sbin is normal since, for the past few years, more and more Linux distributions have been making sbin dirs symlnks to their corresponding bin dirs. For example, on my Arch:

$ ls -ld /sbin /usr/sbin
lrwxrwxrwx 1 root root 7 Jan 31 20:51 /sbin -> usr/bin
lrwxrwxrwx 1 root root 3 Jan 31 20:51 /usr/sbin -> bin

And this is explained in the Arch documentation:

Arch Linux follows the file system hierarchy for operating systems using the systemd service manager. See file-hierarchy(7) for an explanation of each directory along with their designations. In particular, /bin, /sbin, and /usr/sbin are symbolic links to /usr/bin, and /lib and /lib64 are symbolic links to /usr/lib.

This, the merging of the bin and sbin directories by making sbins symlinks to the corresponding bins is becoming more and more common. The folks at freedesktop.org make the case for it here, and I am reproducing some of their main arguments below:

Compatibility: The Gist of It

• Improved compatibility with other Unixes/Linuxes in behavior: After the /usr merge all binaries become available in both /bin and /usr/bin, resp. both /sbin and /usr/sbin (simply because /bin becomes a symlink to /usr/bin, resp. /sbin to /usr/sbin). That means scripts/programs written for other Unixes or other Linuxes and ported to your distribution will no longer need fixing for the file system paths of the binaries called, which is otherwise a major source of frustration. /usr/bin and /bin (resp. /usr/sbin and /sbin) become entirely equivalent.
• Improved compatibility with other Unixes (in particular Solaris) in appearance: The primary commercial Unix implementation is nowadays Oracle Solaris. Solaris has already completed the same /usr merge in Solaris 11. By making the same change in Linux we minimize the difference towards the primary Unix implementation, thus easing portability from Solaris.
• Improved compatibility with GNU build systems: The biggest part of Linux software is built with GNU autoconf/automake (i.e. GNU autotools), which are unaware of the Linux-specific /usr split. Maintaining the /usr split requires non-trivial project-specific handling in the upstream build system, and in your distribution's packages. With the /usr merge, this work becomes unnecessary and porting packages to Linux becomes simpler.
• Improved compatibility with current upstream development: In order to minimize the delta from your Linux distribution to upstream development the /usr merge is key.

[. . .]

Beyond Compatibility

One major benefit of the /usr merge is the reduction of complexity of our system: the new file system hierarchy becomes much simpler, and the separation between (read-only, potentially even immutable) vendor-supplied OS resources and users resources becomes much cleaner. As a result of the reduced complexity of the hierarchy, packaging becomes much simpler too, since the problems of handling the split in the .spec files go away.

The merged directory /usr, containing almost the entire vendor-supplied operating system resources, offers us a number of new features regarding OS snapshotting and options for enterprise environments for network sharing or running multiple guests on one host. Static vendor-supplied OS resources are monopolized at a single location, that can be made read-only easily, either for the whole system or individually for each service. Most of this is much harder to accomplish, or even impossible, with the current arbitrary split of tools across multiple directories.

With all vendor-supplied OS resources in a single directory /usr they may be shared atomically, snapshots of them become atomic, and the file system may be made read-only as a single unit.

As for what is setting them in your PATH, in the case of /usr/local/sbin, that is added by the default /etc/profile file:

$ grep sbin /etc/profile
append_path '/usr/local/sbin'

I can't find where /sbin or /usr/sbin are added though, which is odd. They don't seem to be mentioned in any of the files I can think of that could be setting them. I created a new user, bib2 on my system, and that user has the following PATH:

$ echo $PATH 
/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/sbin:/usr/local/bin

However, apart from /usr/local/sbin, the other sbin dirs aren't mentioned in the obvious places:

$ grep -HR sbin ~/.bashrc ~/.profile ~/.bash_profile \
       ~/bash.login ~/.bash_aliases /etc/bash.bashrc /etc/profile \
        /etc/profile.d/ /etc/environment /etc/security/pam_env.conf \
        /etc/login.defs 2>/dev/null 
/etc/profile:append_path '/usr/local/sbin'
/etc/login.defs:ENV_SUPATH  PATH=/usr/local/sbin:/usr/local/bin:/usr/bin
/etc/login.defs:ENV_PATH    PATH=/usr/local/sbin:/usr/local/bin:/usr/bin
/etc/login.defs:#USERDEL_CMD    /usr/sbin/userdel_local

So these must be defined somewhere else, but I can't find where.