73

Executables are stored in /usr/libexec on Unix-like systems. The FHS says (section 4.7. /usr/libexec : Binaries run by other programs (optional)":

/usr/libexec includes internal binaries that are not intended to be executed directly by users or shell scripts. Applications may use a single subdirectory under /usr/libexec.

On macOS, rootless-init a program called by launchd immediately after booting, is stored in /usr/libexec.

Why would it be stored in /usr/libexec when it is a standalone executable that could be stored in /usr/bin or /usr/sbin? init and other programs not called directly by shell scripts are also stored in folders like [/usr]/{bin,sbin}.

4 Answers 4

65

It's a question of supportability - platform providers have learned from years of experience that if you put binaries in PATH by default, people will come to depend on them being there, and will come to depend on the specific arguments and options they support.

By contrast, if something is put in /usr/libexec/ it's a clear indication that it's considered an internal implementation detail, and calling it directly as an end user isn't officially supported.

You may still decide to access those binaries directly anyway, you just won't get any support or sympathy from the platform provider if a future upgrade breaks the private interfaces you're using.

14

OS X doesn't follow the FHS standard. It has it's own filesystem hierarchy (similar to FreeBSD filesystem hierarchy). The man page hier states:

libexec/- system daemons & system utilities (executed by other programs)

1
  • 5
    Then it seems that /usr/libexec/java_home is definitely in the wrong place in OSX.
    – Frans
    Apr 30, 2020 at 8:30
11

libexec is meant for system daemons and system utilities executed by other programs. That is, the binaries put in this namespaced directory are meant for the consumption of other programs, and are not intended to be executed directly by users.

8

I think it's newer than init - the idea is, like it said, to have executables (so they shouldn't be in /usr/lib) that you would never expect to have in anybody's $PATH.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .