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

2023-02-02 Thread Rasmus Villemoes
On 14/02/2020 12.54, Rasmus Villemoes wrote: > > Assume BOOT_ORDER contains some permutation of "A B C", and for each > letter x, there's a BOOT_x_LEFT counter telling how many boot attempts > that slot has left. Now I want to find the first x in $BOOT_ORDER for > which $BOOT_x_LEFT is positive.

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

2020-02-21 Thread Tom Rini
On Fri, Feb 21, 2020 at 11:32:16PM +, Rasmus Villemoes wrote: > On 18/02/2020 09.11, Rasmus Villemoes wrote: > > > Thanks, Wolfgang. Consider both "env set -E" and the alternative "env > > get" withdrawn. > > So, if I wanted to change the status of such a patch in patchwork, what > would be

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

2020-02-21 Thread Rasmus Villemoes
On 18/02/2020 09.11, Rasmus Villemoes wrote: > Thanks, Wolfgang. Consider both "env set -E" and the alternative "env > get" withdrawn. So, if I wanted to change the status of such a patch in patchwork, what would be the appropriate status? There's no "Withdrawn" or "Retracted". So "Not

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

2020-02-18 Thread Rasmus Villemoes
On 16/02/2020 18.25, Wolfgang Denk wrote: > Dear Rasmus, > > In message <20200216152427.e80c7240...@gemini.denx.de> I wrote: >> >> So lets change my little script to add setting "left": >> >> slot=none >> for i in $BOOT_ORDER ; do >> setenv tmp_cmd 'setexpr tmp_val sub '^' ""

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

2020-02-16 Thread Wolfgang Denk
Dear Rasmus, In message <20200216152427.e80c7240...@gemini.denx.de> I wrote: > > So lets change my little script to add setting "left": > > slot=none > for i in $BOOT_ORDER ; do > setenv tmp_cmd 'setexpr tmp_val sub '^' "" $'BOOT_${i}_LEFT > run tmp_cmd > test $slot

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

2020-02-16 Thread Wolfgang Denk
Dear Martin, In message <2cd28d15-b5bf-4c5b-a57c-b9a24ad6d...@geanix.com> you wrote: > > > I chose to implement boot count / selection functionality as a command > instead: > https://patchwork.ozlabs.org/patch/943549/ Thanks for pointing out, I think I should NAK this patch, too. It can be

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

2020-02-16 Thread Wolfgang Denk
Dear Rasmus, In message <509a01fb-ba01-33b9-33bc-7323544d2...@prevas.dk> you wrote: > > So in bash, that might be written > > slot=none > for x in $BOOT_ORDER ; do > eval "left=\${BOOT_${x}_LEFT}" > if [ $left -gt 0 ] ; then > slot=$x > break > fi > done OK, now I get the context.

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

2020-02-14 Thread Martin Hundebøll
Hi, I chose to implement boot count / selection functionality as a command instead: https://patchwork.ozlabs.org/patch/943549/ I do plan to extend it a bit in the coming weeks though: * move the env-get and -set to weak functions, so that board files can put the info wherever. * add support

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

2020-02-14 Thread Rasmus Villemoes
On 14/02/2020 12.54, Rasmus Villemoes wrote: > Now we can work around the lack of break in the busybox shell by writing ^ > But we still can't translate this to busybox shell, because there's no

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

2020-02-14 Thread Rasmus Villemoes
On 13/02/2020 16.55, Wolfgang Denk wrote: > Dear Rasmus, > > In message you wrote: >> >> I'm sorry, I see I mistyped in my example above, it should have been >> >> if test $slot = "A" ; setenv result $BOOT_A_LEFT ... >> >> as should hopefully be clear from the original post and the eval >>

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

2020-02-13 Thread Wolfgang Denk
Dear Rasmus, In message you wrote: > > I'm sorry, I see I mistyped in my example above, it should have been > > if test $slot = "A" ; setenv result $BOOT_A_LEFT ... > > as should hopefully be clear from the original post and the eval > examples. So to reiterate, the problem is to get the

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

2020-02-13 Thread Rasmus Villemoes
On 12/02/2020 12.38, Wolfgang Denk wrote: > Dear Rasmus, > > In message you wrote: >> >>> 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

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

2020-02-12 Thread Wolfgang Denk
Dear Rasmus, In message <2e076ba8-6ffe-66dc-ecb9-ebb62e47f...@prevas.dk> you wrote: > > >> 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? > > Btw., I also

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

2020-02-12 Thread Wolfgang Denk
Dear Rasmus, In message you wrote: > > > 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

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

2020-02-11 Thread Rasmus Villemoes
On 11/02/2020 22.20, Rasmus Villemoes wrote: > On 11/02/2020 17.30, Wolfgang Denk wrote: >>> 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

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

2020-02-11 Thread Rasmus Villemoes
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 -

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

2020-02-11 Thread Simon Glass
Hi Rasmus, On Tue, 11 Feb 2020 at 08:38, Rasmus Villemoes wrote: > > On 05/02/2020 18.59, Simon Glass wrote: > > Hi Rasmus, > > > > >> 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

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

2020-02-11 Thread Wolfgang Denk
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}} >

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

2020-02-11 Thread Rasmus Villemoes
On 05/02/2020 18.59, Simon Glass wrote: > Hi Rasmus, > >> 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. >> >> Signed-off-by: Rasmus Villemoes >> --- >>

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

2020-02-05 Thread Simon Glass
Hi Rasmus, On Tue, 4 Feb 2020 at 18:08, Rasmus Villemoes 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}} > > This

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

2020-02-04 Thread Rasmus Villemoes
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}} This forces some scripts to needlessly duplicate logic and hardcode assumptions. For