On 21/10/2021 18.03, Tom Rini wrote: > On Thu, Oct 21, 2021 at 09:59:38AM -0600, Simon Glass wrote: >> Hi Marek, >> >> On Thu, 21 Oct 2021 at 07:28, Marek Behún <marek.be...@nic.cz> wrote: >>> >>> On Thu, 21 Oct 2021 15:25:37 +0200 >>> Marek Behún <marek.be...@nic.cz> wrote: >>> >>>> Hello, >>>> >>>> On Thu, 21 Oct 2021 15:06:51 +0200 >>>> Wolfgang Denk <w...@denx.de> wrote: >>>> >>>>> I confirm that '+=' looks better. But '+=" is technically broken. >>>> >>>> a bit of my opinion: >>>> I think =+ will confuse far more people than + as last character of var >>>> name working weirdly. But I also think that + should be supported as >>>> last character. Therefore I propose backslash escaping in variable name, >>>> i.e. >>>> var+=value >>>> appends value to var, while >>>> var\+=value >>>> sets variable with name "var+" >> >> My first preference is to disallow + at the end of an end var. Perhaps >> we can start printing a warning if people do it, for a few releases. >> >> My distance second preference is what Marek has here, using a >> backslash to escape the + character. > > How bad does it make the parser look if we allow trailing + in variable > names, by escaping them? It's seemingly the substantive objection at > this point. >
So I don't understand all the bruhahaha around a + at the end of the varname. Nobody suggests (that I have seen) changing anything about how U-Boot at runtime interprets and handles variables, so all variable names that used to be valid continue to be so. It's just that this _new_ method of generating the environment places certain restrictions on what can be done. The old-fashioned ways (mkenvimage, good'ol CONFIG_ENV_EXTRA_SETTINGS with all its warts, and run-time 'env set') continue to allow people to define whatever env vars they want. This new method is meant for transitioning in-tree boards' default environment, and no in-tree boards need anything exotic. Also, completely independent of whether the subsequent parser is implemented in awk or python or rust, or what syntax it accepts and the semantics of that syntax, the fact that we first pass the input through cpp already means some things just won't work the same way as when given to mkenvimage, and that applies to both sides of the =: printf 'x/* huh */y=/* where did this go ? */\nmsg=I like unix\nfive spaces=5spaces\n' | gcc -E -P -x assembler-with-cpp - x y= msg=I like 1 five spaces=5spaces [In case its broken by the email, there are actually five spaces in the printf string between the words "five" and "spaces", the above should illustrate that cpp collapses those to a single space]. So, I'd much rather we do a cleaner break, and accept (and ignore) whitespace on either side of the assignment operator - that's how Make variable assignments work IIRC. And since a lot of people making use of this will already be familiar with Yocto, I think we should have two compound assignment operators, .= and +=. That still allows one to use any non-whitespace, non-= characters (modulo the restrictions imposed by the whole thing passing through cpp) in variable names, so foo+=abc means foo+ = abc while could append to foo by saying foo += abc That whitespace around the assignment operators would also make the input files somewhat more readable - there really is no point in having human-readable, human-editable text files having a format almost-but-not-quite be that of the on-disk format. Rasmus
