All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wolfgang Denk <wd@denx.de>
To: Tom Rini <trini@konsulko.com>
Cc: Simon Glass <sjg@chromium.org>,
	U-Boot Mailing List <u-boot@lists.denx.de>,
	Heinrich Schuchardt <xypron.glpk@gmx.de>,
	Joe Hershberger <joe.hershberger@ni.com>
Subject: Re: [PATCH v6 4/7] env: Allow U-Boot scripts to be placed in a .env file
Date: Tue, 19 Oct 2021 12:33:11 +0200	[thread overview]
Message-ID: <3546032.1634639591@gemini.denx.de> (raw)
In-Reply-To: <20211018142404.GR7964@bill-the-cat>

Dear Tom,

In message <20211018142404.GR7964@bill-the-cat> you wrote:
> 
> > > Perhaps we should just make "+" an illegal character in the variable
> > > name, for consistency?
> > 
> > And break backward compatibility?  I'd rather see a better
> > definition of the syntax of the environment files, plus maybe a more
> > powerful parser.
> 
> Are there examples today of scripts that use "+" in the variable names?

None that I know of.

> That maybe someone wrote a custom an private thing that uses + in the
> name isn't the best argument.  Someone saying that did would be better.

Yes, I know.  But then, changing existing APIs is not nice.

> Of course yes, if we can just make the parser handle it, without it also
> being a tricky nightmare, that's the better solution.

Exactly.

> > Hm... I can't find it right now but did I not also read about other
> > restrictions to variable names, like they must noch begin with '_'
> > when using this new tool?
> 
> Any invalid characters need to be clearly documented, if they aren't,
> yes.

So far, only NUL and '=' were impossible to use in a variable name.

> > I feel it is wrong to place new restrictions on something that was
> > constant for 21 years, just because our parser cannot parse it...
> 
> Sure.  But if it's also the case that for 21 years no one has been using
> foo+bar, baz+, etc, in their variable names, maybe we just document
> that's not valid and move on?

We cannot know what people have been using in their environemnts.
Even for those boards that are in mainline, the environment settings
used in real life are often totally different.

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@denx.de
Save yourself!  Reboot in 5 seconds!

  reply	other threads:[~2021-10-19 10:33 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-14 18:22 [PATCH v6 0/7] env: Allow environment in text files Simon Glass
2021-10-14 18:22 ` [PATCH v6 1/7] binman: Allow timeout to occur in the image or its section Simon Glass
2021-10-14 18:22 ` [PATCH v6 2/7] sandbox: Drop distro_boot Simon Glass
2021-10-14 18:22 ` [PATCH v6 3/7] doc: Move environment documentation to rST Simon Glass
2021-10-14 18:22 ` [PATCH v6 4/7] env: Allow U-Boot scripts to be placed in a .env file Simon Glass
2021-10-15 14:32   ` Wolfgang Denk
2021-10-15 15:15     ` Simon Glass
2021-10-18 11:58       ` Wolfgang Denk
2021-10-18 13:37         ` Tom Rini
2021-10-18 14:10           ` Wolfgang Denk
2021-10-18 14:24             ` Tom Rini
2021-10-19 10:33               ` Wolfgang Denk [this message]
2021-10-18 18:12             ` Simon Glass
2021-10-19 10:38               ` Wolfgang Denk
2021-10-18 18:12         ` Simon Glass
2021-10-19 10:46           ` Wolfgang Denk
2021-10-19 14:11             ` Simon Glass
2021-10-19 16:09               ` Wolfgang Denk
2021-10-19 16:14                 ` Simon Glass
2021-10-14 18:22 ` [PATCH v6 5/7] sandbox: Use a text-based environment Simon Glass
2021-10-14 18:22 ` [PATCH v6 6/7] doc: Improve environment documentation Simon Glass
2021-10-14 18:22 ` [PATCH v6 7/7] bootm: Tidy up use of autostart env var Simon Glass
2021-10-15 14:45   ` Wolfgang Denk
2021-10-24 19:53     ` Simon Glass

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3546032.1634639591@gemini.denx.de \
    --to=wd@denx.de \
    --cc=joe.hershberger@ni.com \
    --cc=sjg@chromium.org \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    --cc=xypron.glpk@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.