[U-Boot] [PATCH v5 4/5] cmd: nvedit: env import can now import only variables passed as parameters

[Quentin Schulz]

Hi Wolfgang,

On Fri, Jun 29, 2018 at 01:03:25PM +0200, Wolfgang Denk wrote:
> Dear Quentin,
> 
> In message <322e6866c43f4515240ddca9456ee390b6f334c7.1530257385.git-series.quentin.schulz at bootlin.com> you wrote:
> > While the `env export` can take as parameters variables to be exported,
> > `env import` does not have such a mechanism of variable selection.
> >
> > Let's add the ability to add parameters at the end of the command for
> > variables to be imported.
> 
> Thanks!
> 
> > If a variable exists in the current env but not in the imported env, if
> > this variable is passed as a parameter to env import, the variable will
> > be unset.
> 
> I suggest that this isNOT the default behaviour.  I think most
> peaople would expect that this command only adds/replaces
> environment settings, so omitting one value should not cause
> unexpected behaviour.
> 

It's the default behaviour of himport_r.

However, there's already a flag parameter so maybe I could just add an
H_KEEP_VAR flag to keep the current default behaviour of himport_r
(which is in a library) but add the feature you requested in the env
import cmd, that should work I guess.

> But I agree that such behaviour may also be conveniend - I suggest
> that we use an additional option ("-d" ?) to avtiavte it explicitly.
> 

There's already a -d option which basically, if I understood correctly,
tells himport_r to erase the current env and use only the imported env.

Let's add a -k (for H_KEEP_VAR) to tell himport_r we want to keep
variables that aren't in the imported env but requested to be loaded (or
present in the imported env in one of the forms `var` or `var=`).

Does this make sense? Is it the way you see it implemented?

Quentin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180629/ddef64d0/attachment.sig>