/users directory is a container for users' home directories.
In addition to this, it contains a directory called “
for files shared between all users.
Home directory of user.
Files shared between all users.
Executable commands for all users. This directory corresponds to
/usr/local/binin traditional Unix systems.
Object libraries for all users. This directory corresponds to
/usr/local/libin traditional Unix systems.
An index of man pages (as found in
/org/*/man/...). This directory corresponds to
/usr/manin classic Unix and to
/usr/share/manin more modern Unix systems.
Temporary files that are preserved between reboots. This directory corresponds to
/usr/tmpin classic Unix and to
/var/tmpin more modern Unix systems.
In an objectroot-based system, a user's
environment variable assignment might look something like this:
So, to locate a command in the filesystem hierarchy, the shell would search the following three directories:
➀ $HOME/cmd ➁ /users/common/cmd ➂ /hosts/self/cmd
Now; of these directories, the contents of #1 are controlled by the user. The contents of #3 are dependent on the host instance, but normally include basic versions of the most important user commands. The contents of #2 require a little more explanation ...
The shared-by-all command directory—
symbolic links of the following form:
xyzzy → /org/org1/bin/i386-pc-linux-gnu/xyzzy plugh → /org/org2/bin/i386-pc-linux-gnu/plugh ... plover → /org/orgn/bin/i386-pc-linux-gnu/plover
The idea is to populate the directory with links pointing to the executable binaries comprising the default set of commands available to all users.
Note: If desired, the commands can come from different Unix distributions. Say, the base set from GNU with additions from BSD and Plan 9. Also, an individual user can override any command with a version from another operating system distribution.
This arrangement, when compared to the classic Unix approach, has a number of benefits:
It provides a natural selecting and naming mechanism for alternative implementations of the same command. For example, the
awkcommand might be made available to the user in three different implementations as follows:
awk → /org/gnu/bin/i386-pc-linux-gnu/gawk (The GNU Awk) nawk → /org/att/bin/i386-pc-linux-gnu/awk (AT&T's “new awk”) otawk → /org/bwk/bin/i386-pc-linux-gnu/awk (Brian Kernighan's “one true awk”)
It provides a natural mechanism for switching to a specific version of a command, for example to continue using an older version where the current version has introduced a show-stopping bug.
plugh → /org/id/bin/i386-pc-linux-gnu/plugh-120
If needed, the current version continues to be available through its full canonical pathname.
It allows the removal of individual commands from the default set without removing them from the system altogether or disabling them from programs that might be using the canonical name directly.
It allows the creation of command 'vocabularies' independent of the implementations. This makes it easy to switch between vocabularies for testing, security or other purposes, and to copy and distribute vocabularies as compact tarballs (Wikipedia).
When the publisher is untrusted, the symbolic link can be substituted by a “jacket script” that executes the command chroot'ed to
There are additional benefits including secondary benefits that stem from those listed above. Discovering them is left as an exercise to the reader.
The common library directory
/users/common/lib/ is for symbolic
links of the form:
libjpeg.so → /org/ijg/lib/elf32-i386/libjpeg.so
There should rarely be a reason to copy any actual library files into this directory.
Ideally, references to libraries (at link and runtime) should
specify the files' canonical pathname under
So, for example, an elf32-i386 binary that wants to dynamically load the
above mentioned jpeg library simply compiles in the pathname
And as the above pathname typically is a symlink pointing to the current version of the library
/org/ijg/lib/elf32-i386/libjpeg.so → libjpeg.so.7.0.0
the programmer never has to modify their reference to it.
/users/common/lib directory therefore exists mainly for
backward compatibility, to support build environments and commands that
want to see all installed libraries in a single directory.
Over time this directory is expected to become redundant.