On Sat, Nov 20, 2021 at 8:36 PM Wolfgang Denk <w...@denx.de> wrote:
>
> Dear Artem,
>
> In message
> <CAKaHn9KZg13r=pGCo=lv69pbp-s-ew4uxjbvuh9vet+o5j9...@mail.gmail.com> you
> wrote:
> >
> > next examples just demonstrate how its works for already defined env
> > variables which contain other variables (like storred env variables)
>
> Which next examples?
>
> > sure I know about this ! see my prev message please .
>
> Which exact message are you referring to here?
>
> > Why not have this new opportunity ?
>
> I think the suggested code is adding more problems than it solves.
>
> > > have in mind, as you speak of "deep resolve". But then, I'm first
> > > missing an explanation (and documentation) of what "deep resolve"
> >
> > recurrent resolving for variables
>
> Your implementation of recursion has an arbiotrary and undocumented
> depth limit.
we can improve it if it will be really necessary
> Also, I cannot see a way to prevent resolving in case I
> want to keep something like "$foo" in the result.
>
`setenv -r` resolve only bracked vars like ${VAR} if u need keen some
$VAR just use it without brackets
or just use same setenv without -r option - whats a problem ?
> But that's to be expected from such a non-standard way.
>
we can use setenv with -r or without this option (default standard way)
again didn't see problems (setenv -r is special option especially for
non standard way )
> Why don't you stick with what "eval" in a standard shell does?
>
show me please how can i do it via standard way maybe i miss something ?
> > > actually means in this context, i. e. how many levels down you
> > > evaluat. Oh... the code has "int max_loop = 32;" - this is a
> >
> > i think its will be enough
>
> It is a reallybad habt to implement code with arbitrary limits, as
> it will blow into your face (or more likely that of an innocent
> user) rather sooner than later. It's even worse that this limit is
> nowhere documented.
>
> > 1) this option did not broke any exist compatibilities
> > 2) there we talk not only about uboot shell, same time will be useful
> > to have env_resolve for internal c usage, because env_set dont have
> > this feature
>
> I did not say that an "eval" like construct would not be useful.
> But uncontrolled recursion with an undocumented depth limit is
> a problem.
>
> > yes i'm informed about this plans (and think its happens not so
> > soon - but i provide some simple elegant solution already)
> > but again we dont have env_resolve for internal c usage which must be
> > very useful
>
> On the CLI, we use the "run" command to get the desired effect. Yes,
> this is neither perfect nor elegant. But you can use that in C code
> as well.
>
> > will be easy get useful features via simple solution ( deep resolve
> > all vars by one line )
>
> I understand what you want, but this is not a good way to solve the
> problem. I'd really rather see such efforts invested in helping
> Francis with the hush update - which will make such code unnecessary.
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
> Success in marriage is not so much finding the right person as it is
> being the right person.
