/usr/lib vs /usr/libexec

gmartin · 01-23-2006, 08:47 PM

I just installed nagios 1.2 & nagios 1.4 plugins from packages on linuxpackages. Interesting where different things were installed

nagios executable /usr/bin
nagios plugins /usr/lib/nagios/plugins
nagios cgi scripts /usr/libexec/nagios

While I assume the location for these files was in part decided by the package builder, can anyone shed light on general use of the various /usr directories?

Linux.tar.gz · 01-24-2006, 03:06 AM

http://www.pathname.com/fhs/pub/fhs-2.3.html
I'm not sure you'll find exactly want you want, but it can help.

negatratoron · 04-26-2017, 11:38 PM

It would appear that /usr/libexec is an instance of the /usr/lib<qual> directory. What does <qual> mean there?

Didier Spaier · 04-26-2017, 11:41 PM

http://refspecs.linuxfoundation.org/...fhs/index.html

PS Bear in mind that Linux distributions (including Slackware) sometimes may deviate from the FHS, that can be considered as a guideline more than a strict specification. This is especially true below the top level directories and usage vary upon distribution. For instance, documentation sub directories often are stored in /usr/share/doc in many distributions but in /usr/doc in Slackware and derivatives.

Didier Spaier · 04-27-2017, 12:01 AM

Quote:

Originally Posted by negatratoron

It would appear that /usr/libexec is an instance of the /usr/lib<qual> directory. What does <qual> mean there?

Not really. An example of <qual> would be 64, i.e. the 64 bit shared libraries are stored under /usr/lib64.

Instead, /usr/libexec usually stores binaries (and shell scripts in practice).

55020 · 04-27-2017, 02:35 AM

negatratoron, this is an eleven year old thread that you stumbled across. There are many bad things about that, and one of them is that you looked at a 13 year old standard that was superseded long ago.

Here's the up-to-date version: http://refspecs.linuxfoundation.org/...s/ch04s07.html

Quote:

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

Applications which use /usr/libexec in this way must not also use /usr/lib to store internal binaries, though they may use /usr/lib for the other purposes documented here.
Rationale

Some previous versions of this document did not support /usr/libexec, despite it being standard practice in a number of environments. [26] To accomodate this restriction, it became common practice to use /usr/lib instead. Either practice is now acceptable, but each application must choose one way or the other to organize itself.

[26] See, for example, the "GNU Coding Standards" from the Free Software Foundation.