[PATCH v9 3/7] env: Allow U-Boot scripts to be placed in a .env file

[Rasmus Villemoes]

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.behun at nic.cz> wrote:
>>>
>>> On Thu, 21 Oct 2021 15:25:37 +0200
>>> Marek Behún <marek.behun at nic.cz> wrote:
>>>
>>>> Hello,
>>>>
>>>> On Thu, 21 Oct 2021 15:06:51 +0200
>>>> Wolfgang Denk <wd at 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