Hi,
I noticed the following (in 2011.03)
If I do this on the u-boot cmd line:
setenv tst "setexpr.b mode *1000 & 0xe8"
and I do a
printenv tst
I get:
tst=setexpr.b mode *1000 & 0xe8
Note: one slash. But if I do a printenv without argument I get
tst=setexpr.b mode *1000 \& 0xe8
Note the two slashes.
Reason is that printenv when reading one entry directly fetches it from the hash table; no processing of escape sequences is done, while printenv uses hexport_r (or so) which does replace all \ with \
Not sure what the best solution is to resolve this (so no patch) Perhaps printenv should not use hexport_r, or maybe hexport_r should have an additional argument whether or not to escape backslashes. It would be nice to have a consistent output though (and preferably one with only one \ as that is what has been entered in the setenv and what one expects to see when doing a printenv.
There is one other thing to consider.
I want to have this in my default env, so I wanted to add this to CONFIG_EXTRA_ENV_SETTINGS and it would become something like
"tst=setexpr.b mode *1000 & 0xe8\0"
Unfortunately this does not work. as the & is interpreted by cpp. This of course suggests using \& Alas this did not work either. In env_common.o I see a &, but when importing the env himport_r (if I recall the name correctly) also interprets escapes, so in the end I ended up with:
"tst=setexpr.b mode *1000 \\& 0xe8\0"
Which did the trick.
Is it desired to have escape sequence handling while importing the ENV default settings. Personally I'm inclined to say no. I can understand that cpp eats up a \ but it is somewhat hard to understand that if one on the cmd line types a cmd with a single \ it should become \\ in the default env.
Best regards, Frans.
PS: please keep me on cc as I am not on the list)