[PATCH v8 4/8] env: Allow U-Boot scripts to be placed in a .env file

[Wolfgang Denk]

Dear Simon,

In message <CAPnjgZ0RiiCuOgxce1mRv=GLzadWfvq6cgn0oHeSfhXrCOZR9Q at mail.gmail.com> you wrote:
>
> > > var++=fred
> > >
> > > is unambiguous but very confusing. I think it would be better to disallow +
> >
> > It's neither unambiguous nor confusing.  It is assigning to "var++".
>
> What? Can you read that again?

Did so, but didn't get what you might mean?

In the "<name><operator><value>" syntax there is no way to define an
operator that starts with a character that is legal at the end o a
name. Especially since usual escape characters like backslash are
also valid characters in a name.

So if you want to maintain the status quo for variable names, you
must use an operator that has no such needs.

> > It is much easier to change what is new and can be defined at will.

i. e. define an operator that is stil trivial to parse (as in an awk
script) and does not clash with name rules.

> > If we define for example that "<name>=+<value>" appends, then we can
> > also define our own escape rules, for example:
> >
> >         var=fred        assigns
> >         var=+fred       appends "fred"
> >         var=\+fred      assignes the value "+fred"
> >         var=++fred      appends "+fred"
>
> I don't like that at all.

Why not?

Yes, "=+" may be less intuitive than "+=", but then, it's a new
feature, it is esy to use, and it does not clash with any
potentially existing environments.

> It requires an escape for a common case and

Well, I think if appending a value that starts with a '+' charecter
is a "common case", then variable names ending ith a '+' are common
case, too.

And at least my proposal can handle all situations I can think of in
a somewhat reasonable way, and it does not need to place new
restrictions on variable names.

> is very confusing.

Is it?

> Since people will be converting their out-of-tree scripts anyway, they
> can check for this sort of madness at the time. There should be no
> problem.

Agreed.  There should be no problem with my proposal - the last 2 of
the 4 example aboves are pathological situations which will not
happen often.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Microsoft Compatibility:
     your old Windows 3.11 application crash exactly as the new ones.