onBinQuality

What is bin quality?

I believe all commands should be found in a */bin directory.

They should not be stored in a /*bin directory, nor /* directory. The bin quality metric scores these command directories:

1. */bin
2. \*/\*bin
3. \*/\*

with the objective of having the lowest possible bin quality average

So, as ever, "Why?"

Bill Anderson, Al Brumm and I invented the acronym bitmeld just over 30 years ago, while we were at Computer Consoles, in Rochester, NY. In those days we noticed some small-computing concepts when we invented the acronym. Here's a summary of our understanding of the meaning of bitmeld. The complete reference will follow.

• *b*in – from /bin/ary, but home for any executables, binary, script

or _source_able library,

• *i*nclude – when most executables were compiled, the location of

the common header files, which, along with "lib", define the API for
the component.

• *t*mp – a directory for any *t*emporary files, disposable when

a program terminates.  (you might find this useful as a _text_ directory)

• *m*an – the directory for /man/ual pages, concise and precise

definitions of a command, where the command is documented in
<code> man/man1 </code>, function calls in <code> man/man3
</code>, admin commands (likely in "etc") in <code> man/man5
</code>.

• *e*tc – after /etc/etera, the miscellaneous, and or runtime

configuration commands,

• *l*ib – the runtime /lib/raries, object files, and data for the

running program, where object files expose their calling
sequence in <code> man/man3 </code>

• *d*oc – the program /doc/umentation, to contain user and maintenance

documentation.

So, what are these directories for? They hold the necessary constituents of a running program.

There are two other important considerations for a piece of software: where does the program get built, and where is the archive, the source repository, or the component escrow. Bitmeld is unconcerned with these large considerations of the software problem.

Why bother with a notion of bin quality? Each of the above names had strong precedent in the earliest versions (through Version 7) of Unix&reg;. The root directory, grounded at / "slash", invariable offered <code> bin, /tmp, /etc </code>. The first "user" directory /usr, offered <code> /usr/bin, /usr/include, usr/man, /usr/lib </code>.

So, in 1982 - '83, when Bill, Al, and I juggled the letters b, e, i, l, m,/ and /t, it was easy to call the formatted documentation as belonging to the missing d to complete the bitmeld.

If you treat a runtime collection this way, you realize the layering aspects of this view. Unix was conceived to run in mini-computers of its day, when a file-system had limited resources. I remember one Verlyn Erickson published a build paper in the Bell Technical Journal which support the layered view of bitmeld runtime directories. Today, the PATH variable is the biggest visible artifact of this layering. "Search these directories along your PATH" to find the executables. The man command had a sense of its own path; the compiler and the link editor, or program loader had their own sense of path to search for resources. All of these things are related.

To build a program, all the resources to produce a program (with few exceptions) may be found in a similar set of directories in a given layer. So, for example, if you are developing a program in your HOME directory, you should use existing names for your equivalent components. This is a way of saying if you put your headers in your HOME/include directory, your object libraries in HOME/lib/…, your manual pages, in HOME/man/manN… any runtime configuration in HOME/etc/XXXrc, …etc., then, when it comes time to move your work to an integration station, e.g., a GROUP directory, one thing you won't have to change is the directory names of the runtime components.

A project can establish integration conventions: the MANPATH is … the corresponding INCPATH is …, the LIBPATH…. the BINPATH (which is just the PATH variable) … For me, the names for the location of the runtime components was settled long ago.

Today, a common place to install downloaded software is the /usr/local directory, and what directory is added to the user's PATH? /usr/local/bin.

For those of you who've noted, or noticed a handful of /s* directories in the PATH and other usages, I'm not sure, but most of these components belong in an /etc category. Some belong in the / (root), some in the <code> /usr </code> node, and some in the <code> /usr/local </code> node. The drawback of the /s* notation, i.e., <code> /usr/sbin </code> is revealed in the context of mountable file systems. The acid test is: OK, your executables are in <code> /usr/sbin </code>, supported by <code> /usr/slib </code> , and <code> /usr/sinclude </code>. Do you have a <code> /usr/sman </code>? … And this is important: if they are in the same file system, where is it mounted?

I see it as some glorious future day, when the mountable file system is the discriminant of your run-time environment. //To the extent layered-installs aren't supported by mounting a coherent run-time environment as a file system, we are still in the guild age of software development//.

So, lastly, what is the bin quality metric? The quality metric scores your PATH with a 1, 2, or 3, for components ending with "bin" = 1, "\*\*bin" = 2, or "\*/\" = 3. The perfect score is when your PATH average is 1.00. At the moment, my detail, and composite score and the functions I measure these with:

1.42 12    [[ average is 1.42 for twelve directories on PATH
2 3        [[ three score a TWO
3 1        [[ one UGLY three
1 8        [[ EIGHT one's !!
binQ () 
{ 
    paths | sed '
    s/.*bin$/2 &/
    s/.*\/bin/1 &/
    s/^1 2/1/
    /^[^12]/s/^/3 /
    '
}
compQ () 
{ 
    awk '
        { sum += $1; nof[$1]++; count++; }

    END { printf "%4.2f %d\n", sum/count, count
          for (n in nof) print n, nof[n]
    }
    '
}
paths       () { eval echo \$${1:-PATH} | sed 's/::/:.:/' | tr : '\012'; }

$ binQ | compQ; fbdy binQ compQ paths # produced this

1. bitmeld history
2. Tcl code to discover a bitmeld node
3. discussion on NJ Sysadm mailing list
4. code on google, parsing XML
5. Erickson, V. B. and Pellegrin, J. F. (1984), Build - A Software Construction Tool .<br> AT&T Bell Laboratories Technical Journal, 63: 1049-1059. doi: