What are the meanings of /usr/sbin, /usr/local/sbin and /usr/local/bin?
So the question is: Why there are so many directories and what are the meanings of /usr/sbin , /usr/local/sbin and /usr/local/bin ?
Many programs are distributed through archives and we have to build them from source code. Usually they have makefile so it’s quite easy. This process involves creating files in usr/local/lib, usr/local/bin. usr/local/whatever without creating specific folders for a given program.
I think it’s not right because if we need to remove the program we have to manually delete every of its files if the program’s creator didn’t take care of it.
Sergey, please use the Markdown syntax for writing posts on Super User. Having HTML in them makes them really hard to read and edit in plain text.
I hate directory filesystems. why doesn’t somebody invent a filesystem where files are just tagged instead ? On top of it, directories don’t make any sense because inodes allow files to be fragmented. A directory should be an allocated part of the hard drive memory space, not some path, mostly like a partition.
Btw. the normal way to deal with the «uninstallability» issues of locally built programs is to actually build local packages for them. This process is, however, very dependent on the Linux distribution. In case applications support that mode of deployment, modern supplements to the established packaging systems like Flatpack or Docker come to mind.
5 Answers 5
1. Directory structure
/bin/ Essential command binaries that need to be available in single user mode; for all users, e.g., cat, ls, cp /sbin/ Essential system binaries, e.g., init, ip, mount. /usr/bin/ Non-essential command binaries (not needed in single user mode); for all users /usr/sbin/ Non-essential system binaries, e.g. daemons for various network-services. /usr/local/ Tertiary hierarchy for local data, specific to this host. Typically has further subdirectories, e.g., bin/, lib/, share/
2. Installation
I use a package manager wherever possible (e.g. yum or apt-get). This is possible for a very large number of applications, in a few cases you may have to add a repository. My second choice would be lower level packages such as RPMs and compiling from source would be my last resort (but some people prefer this)
Some package managers can install from RPMs (e.g. yum install oddity.rpm )
If you are compiling from source, its probably not a huge step to create your own package so that the system installer knows what you’ve done.
Then your problem reduces to e.g. yum remove packagename
The alternative is to keep good documentation about all sysadmin activities undertaken (I keep a journal in a text file anyway)
I still don’t get the difference between usr/sbin, usr/local/bin and usr/local/sbin. usr/local is said to be specific to this host, aren’t usr/sbin, usr/bin also specific to the host? the second question was about those programs which are not in repos — make uninstall doesn’t work always — so I asked how to delete those ones?
@Sergey This is historic. /usr/(s)bin tended to be mounted from a network filesystem. That is why everything that is needed to boot the machine had to be in /(s)bin . For the most part /usr/local is now used for programs that you install outside of the package manager (which you shouldn’t do).
for manually installed programs that you no longer need just do a regular delete ( rm ). /usr/local is for machine specific data as for network booting systems /usr in often a network share. @Let_Me_Be installing programs from outside the package manager is perfectly fine and can often been required.
@Sergey: If you have two computers, installed from the same medium and later manually add some software to just one of them, traditionally this would go in /usr/local as it is local to that machine and not part of the «standard» set of programs provided by the vendor. As others have said, this historical practice isn’t nowadays much followed by package builders — I suppose software in the standard repositories are effectively treated more as vendor-supplied optional software rather than as user-installed local customisation.
Stuff in all the */sbin directories tend to be only useful for system administrators. You can keep them out of your PATH if you’re a normal user.
The different directories don’t make much sense if you have a single unix machine on a single disk, but make more sense if you have a big system and different partitions. Remember that a lot of these habits were made in the 80’s and 90’s when systems were a bit different.
/sbin tends to be very small. These are utilities that you need when you’re really hosed. You’d put this on a minimal root partition with /root and /lib. Things in /sbin used to be all statically linked, since if your /usr partition is hosed, any dynamically linked apps are useless. fsck is here and statically linked. If you have a dependency on /usr, obviously you can’t fsck /usr/. Of course, if root partition is hosed, you’re very screwed. This is why this is such a small partition — lower the odds of a bad disk block by using very few blocks here.
/usr/sbin binaries are general sysadmin tools where you can at least get to single user mode and mount all your volumes. They are allowed to be dynamically linked.
The separate partitions for /sbin (well, /sbin on / partition) and /usr also make more sense when you remember that backup was very expensive in both time and for tape. If they were on separate partitions, you could schedule them differently.
/usr/local can be a network filesystem. So locally written sysadmin tools that can be shared across many machines sometimes go into /usr/local/sbin. Obviously no network fixing utils can go there.
Again, a lot of things made more sense on big machines in a networked environment on managed machines with multiple volumes, less so with one Linux machine on a single root partition.
Where should a local executable be placed?
I have an executable for the perforce version control client ( p4 ). I can’t place it in /opt/local because I don’t have root privileges. Is there a standard location where it needs to be placed under $HOME ? Does the File System Hierarchy have a convention that says that local executables/binaries need to be placed in $HOME/bin ? I couldn’t find such a convention mentioned on the Wikipedia article for the FHS. Also, if there indeed is a convention, would I have to explicitly include the path to the $HOME/bin directory or whatever the location of the bin directory is?
4 Answers 4
In general, if a non-system installed and maintained binary needs to be accessible system-wide to multiple users, it should be placed by an administrator into /usr/local/bin . There is a complete hierarchy under /usr/local that is generally used for locally compiled and installed software packages.
If you are the only user of a binary, installing into $HOME/bin or $HOME/.local/bin is the appropriate location since you can install it yourself and you will be the only consumer. If you compile a software package from source, it’s also appropriate to create a partial or full local hierarchy in your $HOME or $HOME/.local directory. Using $HOME , the full local hierarchy would look like this.
- $HOME/bin Local binaries
- $HOME/etc Host-specific system configuration for local binaries
- $HOME/games Local game binaries
- $HOME/include Local C header files
- $HOME/lib Local libraries
- $HOME/lib64 Local 64-bit libraries
- $HOME/man Local online manuals
- $HOME/sbin Local system binaries
- $HOME/share Local architecture-independent hierarchy
- $HOME/src Local source code
When running configure , you should define your local hierarchy for installation by specifying $HOME as the prefix for the installation defaults.
Now when make && make install are run, the compiled binaries, packages, man pages, and libraries will be installed into your $HOME local hierarchy. If you have not manually created a $HOME local hierarchy, make install will create the directories needed by the software package.
Once installed in $HOME/bin , you can either add $HOME/bin to your $PATH or call the binary using the absolute $PATH . Some distributions will include $HOME/bin in your $PATH by default. You can test this by either echo $PATH and seeing if $HOME/bin is there, or put the binary in $HOME/bin and executing which binaryname . If it comes back with $HOME/bin/binaryname , then it is in your $PATH by default.
What’s the purpose of $HOME/bin directory?
I have too little quality points to post it as a comment, so: @Terrance has answered the question but the following link adds to the ‘why so many’ part: lists.busybox.net/pipermail/busybox/2010-December/074114.html tldr; there is no need for so many. They are leftovers from hardware limitations from half a century ago.
2 Answers 2
The bin folders are used for executable programs.
Before Ubuntu 19.10 the folder of /bin itself was used for minimal functionality for the purposes of booting and repairing a system. The /usr/bin folder was used for most of the executable programs. Now /bin is symlinked to /usr/bin so they are now one and the same.
$ lsb_release -r Release: 20.04 $ ls -al / total 104 drwxr-xr-x 20 root root 4096 Apr 16 08:28 . drwxr-xr-x 20 root root 4096 Apr 16 08:28 .. lrwxrwxrwx 1 root root 7 Oct 2 2021 bin -> usr/bin $ lsb_release -r Release: 18.04 $ ls -al / total 1459924 drwxr-xr-x 24 root root 4096 Feb 24 07:36 . drwxr-xr-x 24 root root 4096 Feb 24 07:36 .. drwxr-xr-x 2 root root 4096 Feb 24 07:11 bin The /usr/local/bin is used for executable programs that are not managed by a distribution package.
The answer for your $HOME/bin folder is contained in the .profile in your home folder ( /home// ). It ( .profile ) is sourced automatically when you log in.
Contained in the .profile file in your home folder are the following sections (It is all about preference):
# set PATH so it includes user's private bin if it exists if [ -d "$HOME/bin" ] ; then PATH="$HOME/bin:$PATH" fi # set PATH so it includes user's private bin if it exists if [ -d "$HOME/.local/bin" ] ; then PATH="$HOME/.local/bin:$PATH" If either of those bin folders exist they are automatically added to the $PATH when the user logs into their account. It is used for the user’s own private executable programs and scripts. They are primarily used for the user or owner of those folders, keeping them private from other users.