Cannot get Shell-expanded strings working but falls short for me by design anyway about just HOT 5 OPEN

Can you use unexport to avoid polluting sub-shell environments?

unexport ENV

from just.

Thanks for your response. Well, any interaction manually managing shell vars is what I am avoiding for the same reason: it means humans making mistakes from settings which are out of sight in a terminal session on their machine.

We can assume we already have indicated what env we intend with afeldkamp's example current_project := gcloud config get project which is quite deliberately delegating the decision - this avoids duplicate and potentially contradictory paths.

I understand the just utility hasn't been designed with "basically" global variables in mind so it's not a simple ask. This is why I mentioned supporting user defined flags as another way to avoid requiring shell variable handling outside of the justfile such as just test -e dev. Perhaps something as simple as only adding -e <envString> support would satisfy my requirements nicely - although it doesn't satisfy the case of delegation - that's of secondary importance from my POV. Thanks.

from just.

Oh, one other thing, you can override just variables on the command line by putting the overrides after just but before any arguments:

just ENV=dev test

In the above command, ENV is a just variable and not an environment variable. Does that work?

from just.

Thanks for your reply.  I don't see how I can load an environment file globally using that: x'$ENV'.sh <-- error: Shell expansion failed: error looking key 'ENV' up: environment variable not found 

This example by afeldkamp is an example of what I am looking for.  It feels like to me that just variables are not first class citizens and this leads to reliance on env variables.  And yet, I can't turn this ENV variable into something useful because  set dotenv-filename won't work with just vars as in the below

set dotenv-filename := "{{ENV}}.env".  # error

Maybe I could call another recipe in the dependency of every recipe to set up variables for global env settings... IDK if that would work.  Overall, variable scope limitations are coming up against just var vs env var quirkyness, meets up against variable file loading limitation, meets command line argument passing limitations, and something basic like this IMHO shouldn't be that hard in what seems otherwise a very useful tool.  
- What about support for sub-recipies to allow variable sharing?
- What about supporting a getopts style of variable passing on the command line?  (with an option to allow them to be environment vars OR just vars via setting).
Thanks.

from just.

Ah, sorry, you're right. Yah, just environment variables won't work there.

Can you do just -E dev.env test to load the dev environment? This avoids needing to set an environment variable, and is very close to just test -e dev which you suggested above.

from just.