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@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