[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [RFC/PATCH] Env expansion in config files

From: Branko Čibej <brane_at_xbc.nu>
Date: 2003-12-27 13:23:23 CET

Andrew Snare wrote:

>Hi All,
>With digest authentication currently broken for repositories due to a
>problem with Apache's authentication of subrequests, I recently switched
>to using basic authentication over SSL.
>While trying to configure Subversion to accept my private CA, I
>encountered a problem whereby my .subversion configuration files
>are shared across several machines but my home directory is not
>always the same. This means that the ssl-authority-files and
>ssl-client-cert-file configuration directives are useless for me.
>While originally I hoped that relative paths may be treated relative
>to the configuration file, this turns out not to be the case: the
>values get passed as-is to neon, which in turn simply uses fopen()
>on the path provided.

>This got me thinking, and it occurred that env-variable expansion
>in the configuration file would solve the problem.
I think using environment variables is dangerous, in general, because it
makes it so hard to track down problems. However,

>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.

>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.

> * To insert a $ symbol, $$ is used. I think that this is preferable
> to ignoring $ if it's not followed by a { since then something
> even fancier would be required for the corner case where a ${
> sequence is wanted.
> * Anything other use of $ is an error (which will ensure that most
> existing files which use $ are not silently interpreted incorrectly).
>Comments, etc, would be welcome.

>@@ -96,17 +164,27 @@
> /* Read the first line of the value */
> svn_stringbuf_setempty (ctx->value);
> for (ch = getc (ctx->fd); /* last ch seen was ':' or '=' in parse_option. */
>- ch != EOF && ch != '\n';
>+ err == SVN_NO_ERROR && ch != EOF && ch != '\n';
> ch = getc (ctx->fd))
> {
>- const char char_from_int = ch;
>- svn_stringbuf_appendbytes (ctx->value, &char_from_int, 1);
>+ char char_from_int;
>+ switch(ch)
>+ {
>+ case '$':
>+ /* This indicates an environment variable needs to be expanded. */
>+ err = parse_expand_env_in_value (ctx);
>+ break;
>+ default:
>+ char_from_int = ch;
>+ svn_stringbuf_appendbytes (ctx->value, &char_from_int, 1);
>+ }
> }
> /* Leading and trailing whitespace is ignored. */
> svn_stringbuf_strip_whitespace (ctx->value);
And what happens if the loop exited with an error? You should just use
SVN_ERR above. acually, looking at this function, we could do away with
the "err" variable completely...

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 Sat Dec 27 13:24:01 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.