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]. 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: Test (True) Echo $$[desk.name$[desk.n]] Here "Test (True)" or just "Test" behaves like a hypotetical "Expand" command. So, we probably do not need "Expand" on its own. But, I think, allowing variable names to be nested is good for varaibles that have non-static names, like $[desk.nameN], $[fg.csN], $[gt.ENGLISH_PHRASE]. P.S. I'd like to remove obsolete one-letter variables (like $n) in 2.7.x. I think we should restore the warnings for 2.5.x on usage of such variables suggesting to use $[w.name] instead. $[w.name] works in 2.4.x. Any objections? Regards, Mikhael.
