I'm trying to understand the Filesystem Hierarchy Standard. I have looked up both binaries and libraries, and as I currently understand it:

binaries are files of computer-readable code in binary format, that control the CPU and processor directly with bits.

libraries are functions usable by various programs, for convenience sake - like when you require a module in Javascript of PHP.

Is this understanding correct? If it is, why do we still separate libraries and binaries? Some libraries are binaries, right? And some binaries (cat, less, date, rm, cp, etc) are used and reused as though they were libraries... Can someone help explain the difference and help me find better definitions for these two words? Thank you.


Your understanding is mostly correct, but there are a couple of extra things to consider:

  1. 'binary' refers to something that isn't human readable. This usually refers to machine code, but many other files are also binary files in this sense, with most multimedia formats being a good example. The FHS however has a more specific usage for the term.
  2. Libraries can be binary code. In fact, most of the stuff in /lib is going to be libraries compiled to machine code.
  3. While things like cat are used in shell script like calls to code in libraries, they are not libraries in the FHS sense because they can be run by themselves.

As a result of these points, the more common terminology among people who aren't writing standards documents is:

  • Object files: These are natively compiled machine code, but may not even run or be callable. They typically have a .o extension unless they fall into one of the other categories, and are almost never seen on most systems except when building software. I've listed them here because they're important to understanding a few things below.

  • Executable files: These are files consisting of mostly self contained code that can be run directly. They may be either specially formatted object files which can be loaded directly by the kernel (things like cat, bash, and python are all this type of executable), or are interpreted by some intermediary program that is itself an executable (Minecraft, pydoc, and cowsay are all examples of this type of executable). Executables of the first type almost never have a file extension on UNIX systems, while executables of the second type may or may not. This is what the FHS refers to as 'binaries'. They can be run from other executables, but require calling special functions to invoke them (fork() and exec() in C and C++, things out of the subprocess module in Python, etc) and run as a separate process.

  • Libraries: These are files that contain reusable code that can be invoked by another library or an executable. Code in libraries is invoked (mostly) directly by other code once the library is loaded (referred to as 'linking' when talking about compiled code), and runs in the same process as the code calling it. There are three generic types of libraries:

    1. Static libraries: These are the original variety. They consist of an archive file (usually AR format) with a large number of object files inside, one for each function in the library. The object files get linked into the executable that uses them, so an executable that uses just static libraries is essentially 100% independent of any other code. On UNIX systems, they typically have a .a extension. The concept of static libraries doesn't really exist outside of compiled programming languages.
    2. Dynamic libraries: These are the most common type of library used today. A dynamic library is a special object file, typically with a .so extension on UNIX (.dll is the standard on Windows), that gets loaded at run time by executables that use it. Most of what you'll find in /lib on production systems is dynamic libraries.
    3. Modules: This is the equivalent of a dynamic library for an interpreted language. Handling is a little bit different than for a compiled language, and unlike with a compiled language, it's possible for a file to be both a module and an executable (see http.server in the Python standard library for an example).
  • Not to forget script files, which are a special case of executables, as they depend on a binary executable (bash, python) to be run. What's more, scripts in /lib can be meant to be used by other scripts; compare the Python modules. – Murphy Sep 7 '17 at 12:37
  • 1
    That falls under 'interpreted by some intermediary program. Tow of the examples I listed for that (pydoc` and cowsay) are scripts. – Austin Hemmelgarn Sep 7 '17 at 12:39
  • Clarification to #3 - modules are loadable bits of code used to extend functionality. Apache/php modules are a good example for your interpreted scripts part, but kernel modules count too... I'd also add a point to cover the mostly human readable interpreted languages like scripts for the various shells, php, perl, etc which per FHS would go in a /bin or /sbin directory since they are executable programs – ivanivan Sep 7 '17 at 13:19
  • Modules as extensions are more often called plugins. Apache's naming choice was based on the old UNIX standard of calling kernel drivers modules, and that has now become common terminology with web servers (because of marketing), but that's an odd case compared to most other software, which pretty universally uses either 'plugin' or 'extension' when referring to that. – Austin Hemmelgarn Sep 7 '17 at 14:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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