[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[MINTOS] looking for data (was: Re: standard paths)
In <9401180846.AA15380@math.uni-muenster.de>, Bjarne Pohlers <bjarne@math.uni-muenster.de> wrote:
>|>The current mechanism, looking for an enironment variable first and use a
>|>hardcoded path if it ain't there, is not to bad.
>|>
> There is a third way:
I don't like it, but won't reject it either as it enhances the systems
flexibility. Just a few constructive comments:
> in my setup I have a file `c:\etc\host.cnf'
I would prefer /etc or /usr/etc as the standard location of the file. The
drive specifier is taken from UNIXMODE or else it is the current drive.
The file name host.cnf seems rather confusing, as it suggests a relation
to /etc/hosts. The only alternative I can come up with is binconfig (also
misleading), a better name is asked for.
> (yes, the name is currently fixed, but as it is the only fixed name it
> could be easily changed by a utility like fixstk).
Yes, but it would be necessary to change all executables using this file.
So I propose to have an environment variable (preferably the same name as
the standard name of the file, ie HOST_CNF or BINCONFIG) containing the
full path.
> In c:\etc\host.cnf
> there are entries like
> ETCDIR=/dev/u/etc
> LIBDIR=/dev/u/usr/lib
> HOSTNAME=<Guess>
> etc.
The /dev/<drive>/ notation is IMO a bit silly under MiNT, after all MiNT
provides a /dev filesystem that is more like the-real-thing(TM). This,
ofcourse, does not effect your proposal, I merely felt the need to express
my opinion that we should get rid of the outdated Gemdos-goes-Unix tricks.
( :-) for the humor impaired)
> For special programs one could add a line
> PROGRAMNAME_CNF=<location of program special-.cnf file>
> in which setups can be done which affect only one program
>
> c:\etc\host.cnf and the program.cnf-file could be set up by
> install-scripts or programs.
>
> Some of my programs use this feature already and it works quite fine.
Summary:
Executables (binaries as well as scripts) may find the paths and
other data tey need by:
1. Looking for a well documented environment variable. If it ain't
there or has an incorrect value, than by:
2. Looking for the general configuration file, and searching for
the required data in there. If either the config file does not
exist, or else the data is not available or invalid, than by:
3. Using the built-in (hardcoded) data.
Where 1 and 2 are ofcourse optional. Looking for the general
configuration file means: use the path from environment variable
<?????> (not yet defined), or else some standard path (not yet
defined).
Note that the hardcoded data (3) may be changed by either modifying the
sources (including configure script and Makefile) or by modifying the
binary with the aid of a standardised (not yet defined) config-tool. In
the case of scripts (sh/perl/...) you can use emacs/vi/whatever-you-like
as the 'config-tool' :-).
Regards,
Waldi (walra%moacs11@nl.net)