Hello and good morning Ralph,
Ralph Corderoy <ra...@inputplus.co.uk> wrote:
|> For other use cases i would have no problem with a single global
|> .ini-style configuration file and a per-user one with the same syntax.
|
|Aside, I dislike Microsoft's INI files that have appeared in Unix. :-)
|They're not line based, but have context, making them more awkward to
|search and edit with Unix tools.
In my opinion it's even worse for those that became widespread
especially in the network area, presumably because of the existing
mature yacc parser, à la
a {
b = c
d {
e = f
}
}
or mixture of ini-style "[group]"s plus those {} subgroups i also
have seen. But
|> [startup-files]
|> eqn = INSTALLPATH/eqnrc
|
|`startup-files.eqn=INSTALLPATH/eqnrc' might lead to repetition over many
|lines, but it's self-contained; the parser need not track any
|`[section]', and sed can edit it more easily.
that is a suggestion to keep in mind. Even though i now remember
that once i've read the git config manpage first i was insecure
how to actually do it (and i think writing "as-is" didn't work, at
least back then, ..and still). You use it when doing lookups from
the command line, but have to use INI style syntax in the
configuration file. Can be done differently, of course.
All in all i'm without plan yet anyway.
Variables had to go in there if such a thing would come, as in
eqn = ${INSTALLPATH}/eqnrc
or
eqn = ${configure.PREFIX}/eqnrc
i.e., what you say is good.
But, anyway, regarding the thread topic, in my opinion lesser path
search would be the improvement, not an additional library for
this little piece of code, which really could be done differently,
and additional path searches.
And _especially_ so in groff since it silently relies on POSIX
things and even "non-portable" extensions, e.g., realpath(3) is
a XSI extension even today, so then nftw(3) could also be used.
It's in the C library, you get it for free.
And then in a way that is explicit, either through a configuration
option (/ environment variable) or with a new environment
variable, just one more of those, but i don't like that.
Ciao.
--steffen
