From: zlsiial@uts.mcc.ac.uk (A. V. Le Blanc) Subject: Directories (was Re: No /usr/local) Date: 24 Sep 1992 08:43:34 GMT
In article <HEIM.92Sep23153557@luzie.peanuts.informatik.uni-tuebingen.de> heim@peanuts.informatik.uni-tuebingen.de (Gerald Heim) writes:
> - I dont't like directories with several hundred entries, like
> /usr/bin would become (flame: why /usr/bin? we could throw all
> binaries into /bin like it was on my first pc (c:\dos instead of /bin)
I have directed followups to poster; I might summarise, but probably won't.
Please see the final remarks before you flame me.
I would like to try to summarise the discussion which took place some time
ago on the Linux standards list; I hope this will not further offend those
who are (understandably) tired of the /usr/local discussion, but some of
the reasons have not been repeated for various choices that we made at
that time.
When we set up a new system, we are always tempted to imitate other systems
with which we are already familiar. There is much to be said for this, but
there are also some things to be said against it: first, there is not as
much conformity as you might think between the many existing flavours of
Unix; second, most existing systems were not designed with the PC in mind,
and many factors in their design do not apply to a PC setup.
In the end, it was clear that there are advantages to having one directory
which contains only the files which are essential to starting up the
system. In the most recent draught of the file system standard it is
said that 'The /bin directory should contain programs that are vital to
the restoration of other file systems in the case of a corrupting crash.
No executable in /bin should require any other file system to be mounted
to execute correctly.' There is also given a list of the files which
ought to appear in /bin: 'sh init mount umount dd cat ls fsck mkfs' and
other utilities 'as needed'.
In two respects, I think, most existing practice has parted from this
rule, either by moving specified files elsewhere, or by adding other
files.
In my MCC interim versions of Linux, I have always kept 'init' in /etc.
This is because 'init' is not a file which should be executed by a
command 'init', so I don't see why it ought to be on the PATH. Not
even a superuser needs to execute 'init'. For similar reasons I have
put 'update' in /etc, for it should be executed by the system under
ordinary circumstances, not by the user.
On his root disks, Jim Winstead has now started putting 'mount' and
'umount' into /etc as well. I myself am a little hesitant about this;
it is true that the mount commands are usually in /etc on other Unix
systems, but on Linux (1) this conflicts with the rationale in the
file system standard that /etc ought not contain executables, that
/etc ought not be on the PATH even of root, and (2) it should be
possible for ordinary users to run 'mount' to see what is mounted, at
least, and on systems where security is of no importance, it should
be possible for ordinary users to mount file systems; this can be
done easily by making /bin/mount and /bin/umount suid to root.
The additional files which Jim and I have put into /bin are all, I
think, in pretty close agreement with the spirit of the standard;
for example, 'stty' and 'login' are there because under normal
circumstances they are needed for users (including root) to log in
and get a stable system. On the other hand, I think no one has put
'cc' or 'gcc' into /bin, even though I think that is their normal
location on many systems of AT&T style. It would be a seriously
damaged system that required the C compiler to get it back to normal.
The net effect of the standard as it exists in practice is to keep
the important files in one place, and the directory is surely small
enough to be listed easily.
Now, the /usr/bin directory is supposed to contain 'all executable files
from the standard distribution not contained in /bin', and this is
elucidated by the remark that the files in /usr/bin are those 'considered
to be standard to the UNIX system'; they 'should NOT be Linux specific,
but should have the same function as their UNIX equivalents'.
Although the file system standard does not specify a location for
'non-standard' files, I think it is in the spirit of the document that
'non-standard' files ought to go in a limited number of directories;
it probably should have specified /usr/local/bin as one of these. But
the crux of the problem is this: what files are 'standard'? In the
absence of any 'official' document, how are we to go about deciding
this?
Well, the answer which we have adopted in practice is this: files in
the MCC, SLS, MJ, SC.TAMU, etc., releases are probably to be considered
'standard' as far as those releases go. I can't speak for the others,
but if someone writes to me saying that, for example, 'echo' ought to
be in /bin instead of /usr/bin (as someone did recently), I give the
matter a good deal of thought. Also I feel that I ought not to innovate
excessively; to do so would make the MCC users too far out of line with
the rest of the Linux community.
My install scripts do a lot of deleting. I won't delete shared libraries
in /lib, but I do, for example, delete /usr/lib/gcc-lib. A number of the
minor difficulties which appear when people install MCC interim versions
have been caused by my not deleting enough! Now, it does seem according
to the standard that I or Dave Safford or any 'release maintainer' would
be justified in deleting /bin and /usr/bin as part of the upgrade. In
fact, of course, this is just not possible; too many other packages are
installed in these directories for quite good reasons. Hence I have
tended to be cautious about deleting directories.
What are good reasons for putting something else into these directories?
Well, tcsh or zsh ought to go into /bin for some of the same reasons
why sh goes there. It isn't absolutely necessary for rebooting the
system, but as logging in may depend on it for one or another user,
I think it's a good idea. For the same reason, utilities like groff
ought to go into /usr/bin because they duplicate standard Unix utilities.
I certainly feel that uucp, telnet, ftp, and a number of other things
belong in /usr/bin for this reason.
There has been a lot of argument recently about whether other utilities,
such as TeX, for example, should go into /usr/bin. To a considerable
extent this is up to those who distribute these packages. If they
wish to conform to the spirit of the standard, they should (as I see it)
place in /usr/bin those executables which are, or ought to be, standard
(whatever that means), and place the rest in /usr/local/bin.
I don't think that extended discussion of this in comp.os.linux is
a good idea. I believe the Linux-standards list still exists; if not
we could set up a channel at nic.funet.fi. But I think one reason why
the list degenerated was its inability to reach conclusions. We had
a lot of good advice, but there were too many dissentions to arrive at
a consensus. Part of the problem is, as on many smaller and more
manageable committees, that many of the participants had axes to grind:
'I want Linux to look like the ZZZZ system', or 'I want Linux to be
rationally planned in the following way'. The discussions were valuable,
but there was no satisfactory mechanism for terminating them. In the
event, various people have accepted parts of them and ignored other parts;
the standards are not really enforceable.
If you do write to me about this, please don't expect an immediate reply.
I am getting about 100 e-mail messages a day, and it's just too much
to deal with all of them promptly.
-- Owen
LeBlanc@mcc.ac.uk