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

[Tom Rini]

On Fri, Oct 22, 2021 at 10:29:26AM +0200, Wolfgang Denk wrote:
> Dear Simon,
> 
> In message <20211021210847.v10.3.Ie78bfbfca0d01d9cba501e127f446ec48e1f7afe at changeid> you wrote:
> > At present U-Boot environment variables, and thus scripts, are defined
> > by CONFIG_EXTRA_ENV_SETTINGS. It is painful to add large amounts of text
> > to this file and dealing with quoting and newlines is harder than it
> > should be. It would be better if we could just type the script into a
> > text file and have it included by U-Boot.
> >
> > Add a feature that brings in a .env file associated with the board
> > config, if present. To use it, create a file in a board/<vendor>
> > directory, typically called <board>.env and controlled by the
> > CONFIG_ENV_SOURCE_FILE option.
> >
> > The environment variables should be of the form "var=value". Values can
> > extend to multiple lines. See the README under 'Environment Variables:'
> > for more information and an example.
> 
> The README does not contain this information as it has been moved
> into doc/usage/environment.rst
> 
> I think the documentation is lacking a hint that multiline
> definitions will always be separated by spaces.
> 
> > Also support += to allow variables to be appended to. This is needed when
> > using the preprocessor.
> 
> I cannot see what the preprocessor has to do with this feature.  It
> would be useful in any case, even without the preporcessor.
> 
> 
> The documentation reads:
> 
> "Variables can contain `+` characters but in the unlikely
> event that you want to have a variable name ending in plus, put a backslash
> before the `+` so that the script knows you are not adding to an existing
> variable but assigning to a new one::
>  
>     maximum\+=value
> "
> 
> However, '\' is also a legal character in a variable name (and
> doubled backslashes or apostrophes etc. are legal, too), so
> above line should actually set the environment variable "maximum\+"
> to "value".

I feel I should preface this with "I am cranky".  Now I see that I can
indeed do:
=> setenv foo\\bar baz
=> printenv foo\\bar
foo\bar=baz

on a system today.  To what value, I know not.  I can see how you write
some fancy state machine set of scripts where you end up with "foo+bar+"
needing to be set because you do a bunch of probing of things at run
time and concatenate and ... there, we've got a variable that ends in +
(and fwiw, sh says baz+ is a bad variable name, bash gets kinda funny
with it).  I don't see the value in allowing "\" in a variable name, nor
can I make bash nor sh handle that.   We can just disallow "\" in
variable names.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20211022/fa47eb3c/attachment.sig>