On 11/02/2020 17.30, Wolfgang Denk wrote: > Dear Rasmus Villemoes, > > In message <20200205010812.20373-1-rasmus.villem...@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