Jerry Van Baren wrote: > Scott Wood wrote: >> On Thu, Sep 10, 2009 at 08:23:27PM -0400, Jerry Van Baren wrote: >>> fdt set /ether...@f00 interrupts "this is a string" >>> can now handle multiple strings (words) by concatenating them with >>> spaces (quoted strings still work the same as before because of >>> hush's argument parsing) >>> fdt set /ether...@f00 interrupts this is a string >> >> How do you set a string list, then? > > That *is* a string,
No, a string list is not a string. It is a set of strings that have been concatenated, but which retain their individual null terminators (as in the compatible property). > Strings are backwards compatible because the hush parser strips the > quotes so all that that part of Ken's patch does is to extend it to > paste together multiple arguments rather than limiting it to exactly one > argument. The following also produces the original string: > fdt set /ether...@f00 interrupts "this is" "a string" > > I'm more concerned with the [] form because that really is a syntax > change. The original syntax with a single quoted argument will no > longer be parsed if I understand the change (I need to apply the patch > and confirm this): > Old: > fdt set /ether...@f00 interrupts "[33 2 34 2 36 2]" > becomes > fdt set /ether...@f00 interrupts [ 33 2 34 2 36 2 ] > Note that the *must* be a space between "[" and "33" and between "2" and > "]" because the "[" and "]" now have to be separate arguments. This is > what Andy did with "<" and ">" with no public outcry, so it is probably OK. > > -------------------------------------------------------------- > ==== Does anybody have a problem with this syntax change? ==== > -------------------------------------------------------------- I'm not thrilled with it... I'd think the code could be made to handle the [, ], <, or > being in the same parameter as one of the numbers. -Scott _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
