Re: CS_SERVERADDR tag is not handled correctly in ct_con_props

On Tue, Jan 14, 2014 at 8:16 PM, James K. Lowden <[email protected]>wrote:

> a quick tour through my home
> directory yields very few examples of programs that use both a
> configuration file and environment variables.  Of those that do, they
> cover disjoint attributes


The one that popped into my head right away was pip, the Python package
installer. They actually wrote their configuration code in such a way I
believe that every configuration value can get set by command-line option,
configuration file, or environment variable (with a predictable name).
Though I mostly, for whatever reason, tend to stick to the former two. I
have a tendency to use environment variables for configuration when I'm
setting up Jenkins jobs. Configuration files are not so obvious (people
don't go looking in /home/jenkins to see what's configured) but environment
variables can set within a job so this is a good place to set something
where people see it and it applies to all commands. In particular I set an
environment variable for some other tools (py.test, tox) to force them to
use colored output even though they're not writing to a tty. You can look
at pip though -- if you want inspiration.

http://www.pip-installer.org/en/latest/configuration.html


> I've often thought the parser could be simplied if the configuration
> file grammar were simplifed.  Suppose the structure were:
>
> .freeds/
> .freetds/global
> .freetds/host1
> .freetds/host2
>
> with each file representing a server, containing only lines of the form
>
>         # comment
>         option = value


That would be cool. Another alternative is to stay with one official file
and have a syntax for including other files -- esp. if you have the
Apache-style include everything in a directory syntax -- e.g.:

include .freetds/conf.d/*.conf

But I don't feel strongly about this at all -- just a random idea.