[PATCH] RFC: nvedit: support doing one (extra) expansion of the value in "env set"

[Rasmus Villemoes]

On 11/02/2020 17.30, Wolfgang Denk wrote:
> Dear Rasmus Villemoes,
> 
> In message <20200205010812.20373-1-rasmus.villemoes at prevas.dk> you wrote:
>> Currently, there's no way to fetch the value of an environment
>> variable whose name is stored in some other variable, or generated from
>> such - in non-working pseudo-code,
>>
>>   ${${varname}}
>>   ${array${index}}
> 
> HUSH does not support arrays anyway...

Of course not, but they can be emulated by having variables foo0, foo1,
foo2 and programmatically accessing the variable foo$index, if only
there's a way to do that... In a sense, my BOOT_A_LEFT/BOOT_B_LEFT is
also just an array with keys "A" and "B".

>> This forces some scripts to needlessly duplicate logic and hardcode
>> assumptions. For example, in an A/B scheme with three variables
>>
>> BOOT_ORDER # Either "A B" or "B A" depending on which slot was last updated
>> BOOT_A_LEFT # 0..3
>> BOOT_B_LEFT # 0..3
>>
>> when one needs to determine the slot to boot from, one does something
>> like
> 
> Well, there _are_ other ways...

Please do tell. How can I avoid code duplication and access a variable
whose name I generate by string concatenation/variable interpolation?
I.e., I don't want anything like "if test $slot = "A" ; then setenv
result BOOT_A_LEFT ; elif test $slot = "B" ; then setenv result
BOOT_B_LEFT ; fi", because that doesn't scale.

>> This has been lightly tested in the sandbox. I'll add some proper unit
>> tests, update the help texts and try to handle the Kconfig issue if
>> this is something that might be accepted.
> 
> I'm pretty sure this will blow up in your face in real life, because
> if side effects on existing shell scripts even if you don't
> expect this. 

How so? The behaviour is completely opt-in per "env set", so nothing at
all changes for existing scripts, and it's only supposed to be used
where one would otherwise use some eval-like construct in a "normal"
shell. So

  env set -E result "\${BOOT_${x}_LEFT}"

corresponds to

  eval "result=\${BOOT_${x}_LEFT}"

And just as "eval" is used sparingly in shell scripts, I expect "env set
-E" to be used only when necessary.

> This needs _lots_ of testing with existing code /
> scripts.

I'm not proposing changing semantics of existing scripts at all.

Thanks,
Rasmus