Dear Wolfgang,

Thank you for your reply.

On 04/09/2014 02:50 PM, Wolfgang Denk wrote:

Dear James,

In message 5345B6EC.6050109@gmail.com you wrote:

...

I'd like to store the values of environment variables in HUSH shell variables and then restore them later. My ultimate goal is to preserve a few environment variables through a "env default -f".

It is probably easier to use "env export" to store this set of variables to some area in memory. You could even make this permanent by writing it to flash or some storage device.

I hadn't thought of exporting the environment to memory, excellent idea.

...

I'm working with U-Boot 2010.12. Changing to a newer version is not possible at this time.

Heh. As soon as you have to change _any_ code, you can as well upgrade.

I was hoping (in vain perhaps) to do my work modifying only the environment.

...

I realize this is a very old U-Boot. I'm hoping that the relevant parts of U-Boot have not changed between that old version and versions you might provide help for.

Well, a ton of bug fixes and improvements have been added since. One of the extensions you want and which has been added only after v2010.12 is the capability to export only a sub-set of the environment (i. e. a list of variables passed on the command line).

This is a definite drawback to having an old U-Boot; I'm sure I would benefit from the bug fixes and other enhancements.

Exporting a list of values sounds like a nice addition that would be helpful to me.

...

=> for i in $e; do v_$i=$i; done

...

...

What I get:

...is exactly what you coded. You would get the same in any other shell, too.

...

=> showvar HUSH_VERSION=0.01 v_e=e ethaddr ipaddr rootpath v_ethaddr=00:00:17:88:09:36 v_ipaddr=10.3.134.80 v_rootpath=/home/anyuser/a/device/tr/rootfs =>

So, how do I re-write the for loop to get the desired results

This would require an "eval" or command substitution, which we do not have in our implementation of the hush shell.

"eval" seemed to me also to be what I wanted. I'm aware it isn't present in hush, but I was hoping for some magic from the community. :-)

To me it seems the easiest way to get what you want is to use "env export ... ethaddr ipaddr rootpath" or similar.

I suppose, with my 2010.12, I could export everything to memory and then parse through it to find the values I need then import them. Sounds vaguely possible but it's probably more complex than doing the U-Boot upgrade.

Um... yes, this requires an update to more recent code.

Yes, update is on my to-do list, but schedules dictate that the upgrade is not my first priority. The conclusion reached here adds to the argument for doing it sooner rather than later.

Best regards,

Wolfgang Denk

Thank you again for you comments. Jim

Dear Wolfgang,

With your help, I have satisfied my need.

On 04/09/2014 11:52 PM, Wolfgang Denk wrote:

Dear James,

In message 5345D493.4080803@gmail.com you wrote:

...

...

Heh. As soon as you have to change _any_ code, you can as well upgrade.

I was hoping (in vain perhaps) to do my work modifying only the environment.

Yes, I understand this. But I have to admit that I don't see an easy way.

Hm... thinking about it, you _can_ do this, but it's a bit ugly...

POC code:

=> print ethaddr ipaddr serverip ethaddr=00:10:ec:01:08:84 ipaddr=192.168.100.6 serverip=192.168.1.1

=> echo E=$foo_ethaddr I=$foo_ipaddr S=$foo_serverip E= I= S=

=> setenv setvar 'setenv tmp "foo_$arg=$$arg"'

=> for arg in ethaddr ipaddr serverip ; do

...

run setvar run tmp echo E=$foo_ethaddr I=$foo_ipaddr S=$foo_serverip done

E=00:10:ec:01:08:84 I= S= E=00:10:ec:01:08:84 I=192.168.100.6 S= E=00:10:ec:01:08:84 I=192.168.100.6 S=192.168.1.1

As you can see, I'm useing a two-step approach to first constuct a command and then to run it. This "consumes" 2 environment variables ("tmp" and "arg"), but this should be an acceptable price...

Extending this a bit further to include yet another env var, I have the following that allows a list to be saved and restored.

=> setenv setvar 'setenv tmp "v_$arg=$$arg"' => setenv usevar 'setenv t v_$arg;setenv tmp "setenv $arg $$t"' => And testing these: => setenv list "ipaddr ethaddr list" => printenv ipaddr ethaddr ipaddr=10.3.134.80 ethaddr=00:00:17:88:09:36 => => # to save => for arg in $list; do run setvar; run tmp; done => showvar HUSH_VERSION=0.01 arg=list v_ipaddr=10.3.134.80 v_ethaddr=00:00:17:88:09:36 v_list=ipaddr ethaddr list => => # simulate "env default -f" => setenv ethaddr; setenv ipaddr; setenv list => => # to restore (note use of v_list rather than list) => for arg in $v_list; do run usevar; run tmp; done => printenv ipaddr ethaddr list ipaddr=10.3.134.80 ethaddr=00:00:17:88:09:36 list=ipaddr ethaddr list =>

Perhaps this isn't as nice looking as it could be. But, it does solve the problem at hand, which has value for me. The solution boils down to two definitions in the default environment (setvar and usevar) and then a single script line to save the values and another single script line to restore them. I don't consider this addition burdensome at all.

And to paraphrase a former US Sec Def, "You code with the tools you have rather than with the tools you might like to have."

Setting temporaries to commands that are then executed as a means to getting evaluations done when needed seems like a great addition to the "bag of tricks"

...

The new env command allows for a lot of interesting features, ...

I look forward to using these new facilities.

And, I appreciate you help very much.

Best regards, Jim