Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Let's get clear with all bin and sbin folders(from filesystem hierarchy standard):

  • /bin is for system-level binaries
  • /sbin is for other system-level binaries mostly for the boot loader and system administrators
  • /usr/bin is for not essential binaries
  • /usr/sbin - this is where mess starts - not essential tools for for system administrators? What does it mean? For experiments?
  • /usr/local/bin - no word about this folder
  • /usr/local/sbin - locally installed system administration programs. Again? How about /usr/sbin?

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.

Why is it so?

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.

share|improve this question
    
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. –  slhck Aug 19 '11 at 12:36
    
Okay, I'll try to –  Sergey Aug 19 '11 at 13:14
    
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. –  jokoon Aug 19 '11 at 19:20
    
On [FilesystemQA] there is this explanation: askubuntu.com/questions/138547/… –  d14gf58g74f58g May 23 at 13:15
add comment

4 Answers

up vote 13 down vote accepted

1. Directory structure

This should be covered in the Filesystem Hierarchy Standard (2.3 PDF)

/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)

share|improve this answer
1  
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 Aug 19 '11 at 12:49
1  
@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). –  Let_Me_Be Aug 19 '11 at 12:55
    
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. –  Lamar B Aug 19 '11 at 16:00
    
@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. –  RedGrittyBrick Aug 19 '11 at 16:14
add comment

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.

share|improve this answer
add comment

You really should have your second question be a separate question here on Superuser. It's unrelated to the first.

Yes, having files all over the place sucks. That's why there are many packaging solutions. RedHat created RPM which is used everywhere. Solaris had their package format. HP/UX had theirs, and there's apt and many other package formats. Keep things in the right places (/usr/bin, /usr/lib) as appropriate, but allow easy addition and removal.

For source, there used to be tools that would let you configure and install in a subdir of /usr/local and it would handle symlinks to /usr/local/bin for you. Since the wide proliferation of package tools, this is less necessary, and I forgot their names.

Some people like to install in /opt/packagename and keep everything together there. The good: everything is in one directory and an uninstall is rm -rf /opt/packagename. The downsides to this are having to add /opt/packagename/bin to everyone's PATH, and the fact that people usually don't put /opt on a separate partition, and you fill up the root partition.

share|improve this answer
add comment

To answer your second question:
Usually programs are distributed with a so-called package manager. A package manager usually fetches binary packages (software compiled for a certain platform) and tosses it around directories (there are some who download the source code, compile it on your machine and install it). Thus, the package manager knows where the files belonging to certain "program" (package) are residing, and when you want to remove the package, package manager takes care of cleaning up everything.
Even when you compile the source code on your own with

make

and install it with

make install

you can usually do

make uninstall

which deletes the files from the file system.

share|improve this answer
    
make uninstall may be done only in the programmer added this process to the make file. the question was - how to delete those ones where make uninstall doesn't work? –  Sergey Aug 19 '11 at 12:50
    
Correct, but I think it's quite difficult to find a serious project without uninstall in makefile (never had problems with that). If you compile from source, and makefile doesn't have uninstall, then I think it's not a easy way to do it, but you can still write a script that parses make install output and deletes files which are mentioned there. –  Matej Repinc Aug 19 '11 at 13:05
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.