Coda File System

configuration style

From: Ivan Popov <>
Date: Sat, 12 Jan 2002 21:25:04 +0100 (MET)

In short - I'm advocating for an environment variable to locate the *.conf
file. Cheap to implement, easy to use, breaks nothing, it will be much
easier to manipulate configurations.

(I'm involved in a system administration project, relying on global
filesystems, on one side, and I'm an everyday Coda user and admin, on the
other side.)

Rationale (long, just skip it :) :

The current Coda approach is:
 - read a configfile with a hardcoded name.
It's "almost good".

It makes it impossible to put the config file into a certain filetree
chosen after compilation. It makes it hard to impossible to isolate
different configurations from each other. It makes it hard to
support Coda in a "non-standard" environment.

There are already some platform-dependent tweaks in scripts, that are
essentially unnecessary (they mirror the different filesystem structures)
and make it harder to make Coda work under different circumstances. All
Coda {config,pid,lock} files could lie in one and only tree, that would be
really easier to understand and support than it is now.
If you for some reason feel FHS (the "Filesystem Hierarchy Standard") is
important, just place things under-and-relative-to that tree according to
FHS, then it will be a lot easier to locate files than in the common very
polluted FHS tree anyway.

(note that binaries do not have to be present in the same tree, but it is
not a big deal if they are, a couple of symlinks from the tree would make
it possible to place binaries independently. the important part is to not
"hardcode" paths as it is now - I have to clean the scripts manually...).

(The current script-editing by configure and make breaks easily - breaks
for me at any rate - as it relies on certain assumptions that just happen
to be valid "most of the time").

The small change that would solve most of the issues is - to check an
environment variable for the config file name (full path of course) -
or add a command line switch like --config <path> to all of the utilities
(it seems more complicated and hence unneeded).

Of course, no hardcoded paths should be present. There are a couple of
places with /vice as the only choice - in scripts (in norton too?), but in
general the source seems to be rather consequent about reading the file.
A small change now would make a big gain.


Received on 2002-01-12 15:28:03