On Sun, 18 Sep 2005, Mikhael Goikhman wrote:
On 18 Sep 2005 15:54:51 +0200, Dominik Vogt wrote:
On Tue, Sep 13, 2005 at 08:16:29AM +0200, Viktor Griph wrote:
I've written a patch to allow nesting of variables as
in $[desk.name$[desk.n]].
I wonder if we actually want to do that. I mean, what happens if
the value of a variable happend to contain "$w" or something?
This patch only adds expanding when $[...] or $w appear inside another
$[...]. The result of such expanding is not expended again in the same
command. If a user has several commands one in another, and does not want
unexpected expanding, he should simply not place a dollar inside $[...],
or prefix these subcommands with "-". I don't think there is a real-life
example that shows a problem with unintentional expanding here, it is
all fully controllable by a user.
Actually, this patch is a bit conservative and expands less than I would
like to. For example, $[fg.cs$d] and $[gt.$n] are always expanded (this
is correct although makes no much sence), but $[UNEXISTING_$[desk.n]_VAR]
is left as is. I would expect it to possibly become $[UNEXISTING_0_VAR].
That wouldn't be that hard to change. Maybe will get some time this week
to look at it, but today I have no time for it.
I planned to commit this patch, because I saw several configs that use
tricks to do $[desk.name$[desk.n]]. BTW, this is already possible using:
Just hold on for a while. I just realized that I might had introduced a
memory leak, by not freeing the variable_name obtained while expanding the
nested name :o. I'll have to check into that before you go around and
commit anything. Most likely it's just to add a free(variable_name) at the
end of expand_extended_vars, but for doing the expansion refered to above
the output would have to become created with the variable_name before
returning. I'll try to find sometime this week to check on this.
/Viktor
