Dear Artem,
In message 20211119043647.1251416-1-art@khadas.com you wrote:
Add possibility setup env variable with additional resolving vars inside value.
Hm... if you want to evaluate variables, you should not prevent the shell to do that by enclosing them in apostrophes?
Usage examples:
=> setenv a hello; setenv b world; setenv c '${a} ${b}' => setenv -r d '${c}! ${a}...' => printenv d d=hello world! hello...
Without any new code added:
=> setenv a hello; setenv b world; setenv c ${a} ${b} => setenv d ${c}! ${a}... => printenv d d=hello world! hello...
I know very well that this does not cover all use cases you might have in mind, as you speak of "deep resolve". But then, I'm first missing an explanation (and documentation) of what "deep resolve" actually means in this context, i. e. how many levels down you evaluat. Oh... the code has "int max_loop = 32;" - this is a limitation mentioned nowhere. And are you really sure this is a clever idea? I am not convinced. If we do something like this, we should not invent a new non-standard way. We should implement standard shell behaviour instead (i. e. for example something like the eval command).
Artem Lapkin (2): env: setenv add resolve value option test: env: deep resolve value testing
This is one more of the patches that actually try to fix existing problems with our ancient verion of the hush shell. As far as I understand, Francis (added to Cc:) has started working on an update of hush to a current version. We should rather help him with that instead of implementing non-standard workarounds.
Best regards,
Wolfgang Denk