>> Here's an ugly hack that allows you do that using envdir:
>> set -a
>> eval $({ env; envdir ../.env env; } | grep -vF -e _= -e SHLVL= | sort | uniq -u)
>> set +a
Ugh, in the morning (almost) light it's even uglier than I thought,
because it won't work for values you *change* either, which could
be important for things like PATH. Or if values contains a _=
or such.
Try this instead:
set -a
eval $(envdir ../.env env | grep -v -e ^_= -e ^SHLVL=)
set +a
It will reexport all the variables you already have, which is
also ugly, and it still won't remove anything, but at least it
will pick up changes to existing variables.
Ah, the shell. Everytime I doubt whether execline was worth
writing, it only takes a few minutes of /bin/sh scripting to
renew my confidence.
> It will work fine. I'm attempting to pre-load values that will remain
> constant inside the scope of the script, so there isn't a need to change
> them at runtime.
My point is, if you are using this construct in run scripts, remember
the scripts will inherit some environment from init - that could contain
system-wide settings such as PATH or TZ. If for some reason you need to
remove or modify those variables in a specific script, it is important
that it works as expected. :)
--
Laurent
Received on Thu Jan 08 2015 - 11:27:36 UTC