[U-Boot] hashtable lib and escaping
Hi,
I used to have a working setup using U-Boot 2009.03 before upgrading to U-Boot 2012.07. The problem I'm facing is related to the escaping policies of lib/hashtable.c.
What I did before was for example having something like this in my default environment:
bootcmd=run first_boot first_boot=setenv bootcmd my_select;run ubi_boot;saveenv;boot
The trick accomplished was that the environment was saved after setting the real bootcmd (to "my_select;run ubi_boot") on first boot so that the booted OS could always be relying on a valid environment in one of the flash env partitions.
With the escape parsing of himport_r(), the '' is simply dropped and it is no longer possible to escape ';' so the "run ubi_boot" is immediately executed and nothing is saved... The function header mentions the possibility for multi-line values but this should not come at the cost of not being able to escape ';'.
I am not sure about what other uses the escape may have or used to have so I have not come up with a patch yet. Does anyone have any feedback/opinions concerning this?
BR // Mats
Dear Mats Kärrman,
In message ED3E0BCACD909541BA94A34C4A164D4C425CEE7A@post.tritech.se you wrote:
I used to have a working setup using U-Boot 2009.03 before upgrading to U-Boot 2012.07. The problem I'm facing is related to the escaping policies of lib/hashtable.c.
What I did before was for example having something like this in my default environment:
bootcmd=run first_boot first_boot=setenv bootcmd my_select;run ubi_boot;saveenv;boot
THis syntax has never been correct. If it ever worked, than only by chance (read: because of incorrect/imperfect code).
With the escape parsing of himport_r(), the '' is simply dropped and it is no longer possible to escape ';' so the "run ubi_boot" is immediately executed and nothing is saved... The function header mentions the possibility for multi-line values but thi s should not come at the cost of not being able to escape ';'.
You have to be casreful here and keep in mind that (de-) escaping will take place in a different places: himport() (resp. setenv()) is only one part of this story - the other part is when you will actually pass this string to the command processor (the shell).
See here:
=> setenv foo 'echo part one;echo part two' ; print foo ; run foo foo=echo part one;echo part two part one part two => setenv foo 'echo part one\;echo part two' ; print foo ; run foo foo=echo part one;echo part two part one;echo part two =>
Best regards,
Wolfgang Denk
Thanks, but... If not correct, then what is this supposed to mean (common/main.c :: builtin_run_command()):
/* * Find separator, or string end * Allow simple escape of ';' by writing ";" */
This does not indicate "by chance", or was it something else that was not correct? BR // Mats
From: Wolfgang Denk [wd@denx.de] Sent: Thursday, November 01, 2012 9:00 PM To: Mats Kärrman Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] hashtable lib and escaping
Dear Mats Kärrman,
In message ED3E0BCACD909541BA94A34C4A164D4C425CEE7A@post.tritech.se you wrote:
I used to have a working setup using U-Boot 2009.03 before upgrading to U-Boot 2012.07. The problem I'm facing is related to the escaping policies of lib/hashtable.c.
What I did before was for example having something like this in my default environment:
bootcmd=run first_boot first_boot=setenv bootcmd my_select;run ubi_boot;saveenv;boot
THis syntax has never been correct. If it ever worked, than only by chance (read: because of incorrect/imperfect code).
With the escape parsing of himport_r(), the '' is simply dropped and it is no longer possible to escape ';' so the "run ubi_boot" is immediately executed and nothing is saved... The function header mentions the possibility for multi-line values but thi s should not come at the cost of not being able to escape ';'.
You have to be casreful here and keep in mind that (de-) escaping will take place in a different places: himport() (resp. setenv()) is only one part of this story - the other part is when you will actually pass this string to the command processor (the shell).
See here:
=> setenv foo 'echo part one\;echo part two' ; print foo ; run foo foo=echo part one;echo part two part one part two => setenv foo 'echo part one\\;echo part two' ; print foo ; run foo foo=echo part one\;echo part two part one;echo part two =>Best regards,
Wolfgang Denk
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de "No matter where you go, there you are..." - Buckaroo Banzai
Dear Mats Kärrman,
please don't top post/full quote. If needed, please read http://www.netmeister.org/news/learn2quote.html
In message ED3E0BCACD909541BA94A34C4A164D4C425D0244@post.tritech.se you wrote:
If not correct, then what is this supposed to mean (common/main.c :: builtin_run_command()):
/* * Find separator, or string end * Allow simple escape of ';' by writing "\;" */
As I metioned, this is the _second_ part of escaping, that which happens when processing the commands. The first part happens when reading the environment.
The examples I gave should show pretty well how it works:
See here:
=> setenv foo 'echo part one\;echo part two' ; print foo ; run > foo foo=echo part one;echo part two part one part two => setenv foo 'echo part one\\;echo part two' ; print foo ; run> foo foo=echo part one\;echo part two part one;echo part two =>
Here is one more:
=> setenv foo echo part one\;echo part two ; print foo ; run foo foo=echo part one;echo part two part one;echo part two =>
Best regards,
Wolfgang Denk
Thanks for your advice. I did not say so, but I'm primarily relying on the default environment and not so much the command line. I see now how to make this work by providing the necessary amount of backslash'es. Maybe it was your statement:
THis syntax has never been correct. If it ever worked, than only by chance (read: because of incorrect/imperfect code).
that set me off wrong, because in 2009.03 (before the introduction of hashtable) it did work and there were no confusing parsing of escapes. Still the parsing I see now is not exactly user friendly, example (U-Boot 2012.07):
=> setenv foo echo part one\;echo part two => print foo foo=echo part one\;echo part two => run foo part one;echo part two => printenv foo foo=echo part one\;echo part two => printenv <snip> foo=echo part one\\;echo part two <snip>
here the run and print commands yields the expected result based on the setenv but not "printenv" alone, and my results does not match your example which were
=> setenv foo echo part one\\\;echo part two ; print foo ; run foo foo=echo part one\;echo part two part one;echo part two
Best Regards, Mats
Dear Mats Kärrman,
In message ED3E0BCACD909541BA94A34C4A164D4C425D1384@post.tritech.se you wrote:
that set me off wrong, because in 2009.03 (before the introduction of hasht able) it did work and there were no confusing parsing of escapes.
That's not true. AFAICT, quoting resp. escape rules haven't changed at all, with a single exception: the old code did not support multi-line variables, i. e. variables containing newline characters.
Still the parsing I see now is not exactly user friendly, example (U-Boot 2 012.07):
=> setenv foo echo part one\\\;echo part two => print foo foo=echo part one\\;echo part two
This is not what I'm seeing.
here the run and print commands yields the expected result based on the set env but not "printenv" alone, and my results does not match your example which were
=> setenv foo echo part one\\\;echo part two ; print foo ; run foo foo=echo part one\;echo part two part one;echo part two
Any chance that you are not using the hush shell, but the old, simple command interpreter?
I don't think this has seen much (if any) testing lately, so it is well possible that there are bugs there...
Best regards,
Wolfgang Denk
Hi,
Any chance that you are not using the hush shell, but the old, simple command interpreter?
Yup, a 100% chance. As I wrote before I rely only on the default environment, apart from development work, so I removed everything I don't need, hush included. With some luck I will have time to look more at this later on.
Best regards, Mats
participants (2)
-
Mats Kärrman -
Wolfgang Denk