Andrew Snare wrote:
>On Sat, Dec 27, 2003 at 01:23:23PM +0100, Branko ??ibej wrote:
>
>
>>>The ConfigParser module from python doesn't support this feature,
>>>so there is no obvious guidance in terms of syntax. However, I
>>>imagine something like Unix-shell expansion is unambiguous, relatively
>>>simple and should not break many existing configuration files.
>>>
>>>
>>>
>>>
>>We already have a syntax for expanding variables. If people really,
>>really want env var expansion, I'd use the standard "%(NAME)s" syntax,
>>but expand from environment variables _only_ in the [DEFAULT] section.
>>
>>
>
>How do we distinguish between internal options and environment variables
>as the intended target of expansion? I'm not sure if you intended to
>suggest it, but all-caps is not sufficient since environment variables
>can be mixed case (although this is not usually the convention).
>
>
Simple -- options always take precedence over the environment.
>>>Since the parser (in config_file.c) is fairly simple, I've created
>>>the attached patch which implements the following rules:
>>>
>>>* Expansion is of the form ${ENV} where ENV is the name of the
>>> environment variable being inserted.
>>>* A non-existent environment variable expands as nothing (it's
>>> not an error).
>>>
>>>
>
>
>
>>This is wrong. Silently ignoring invalid entries in the config file is a
>>recipe for disaster.
>>
>>
>
>I guess it depends on what you mean by invalid. At least in the
>Unix world, the shell silently expanding non-existent environment
>variables is expected (and anticipated) behaviour. Admittedly, the
>most common pattern where the behaviour is used is when testing
>whether it's defined or not. Some shells also allow one to make it
>an error if you attempt to expand an environment variable that
>doesn't exist.
>
>My motivation for not making it an error was related to my experiences
>with the openssl configuration format. It also allows environment
>variables to be imported, and it's an error if the environment
>variable is not set. However this causes a lot of pain since it
>means that often a heap of environment variables must be set, even
>if the command you're invoking doesn't make any use of it. I can
>give concrete examples, if required.
>
>A reasonable compromise, I hope, would be to take advantage of the
>lazy expansion and only make it an error if it's required during
>the svn_option_get expansion but not present. To give a concrete
>example, should it matter if the config file references SSL_CA_CERT
>but no use of https is made?
>
>Finally, it's worth noting that the existing expansion syntax fails
>silently if an expansion is requested but the target does not exist.
>(I call it silent since it simply leaves the expansion tokens
>untouched.)
>
>
IIRC it doesn't fail silently, it leaves the placeholder in the expanded
string -- that's by design.
[...]
>Finally, do the following rules sound acceptable for environment expansion:
>
> * Syntax is of the form %(env_var)s.
> * Only allowed in the [DEFAULT] section.
> * Internal options are tried first, and over-ride a search of the
> environment.
> * As is currently the case, an expansion for something that doesn't
> exist results in the '%(var)s' token being left untouched.
>
>Hopefully these rules are acceptable. I don't mind coming up with a patch
>that implements the change if no-one objects.
>
>
I can accept these rules, except for using env vars at all. But I'm
biased in this area, so I'd rather leave this to a vote.
--
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 30 18:57:44 2003