Dear Frans Meulenbroeks,
In message CACW_hTa_8=u=QppRO9SnAycPqu786XP-md7R3BEFjcjwnYjWxQ@mail.gmail.com you wrote:
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.
Yes, this is a known (not widely, but still) inconsistency. I didn';t know of a good way to fix it, so I left it unchanged.
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 \
Correct.
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.
The reason to use hexport_r() here is so we are able to copy & past the output of printenv into a text file, which later can be used as is with "env import".
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.
...in the default env settings as processed in a C file though CPP.
I think you should use the external storage representation as reference, i. e. what U-Boot creates with env export, and what it reads with env import.
There must be a way to deal with escapes. The current implementation tried to compromize between ideally no changes to previous behaviour on one side (even maintaining binary compatibility to the stored environments olf older versions), and a consistent way to import and export variable settings on the other side.
PS: please keep me on cc as I am not on the list)
Subscribe?
Best regards,
Wolfgang Denk