Best Way to Set Environment Variables in Calling Shell

Can a shell script set environment variables of the calling shell?

Your shell process has a copy of the parent's environment and no access to the parent process's environment whatsoever. When your shell process terminates any changes you've made to its environment are lost. Sourcing a script file is the most commonly used method for configuring a shell environment, you may just want to bite the bullet and maintain one for each of the two flavors of shell.

How to set environment variables from .env file

If your lines are valid, trusted shell but for the export command

This requires appropriate shell quoting. It's thus appropriate if you would have a line like foo='bar baz', but not if that same line would be written foo=bar baz

set -a # automatically export all variables
source .env
set +a

---

If your lines are not valid shell

The below reads key/value pairs, and does not expect or honor shell quoting.

while IFS== read -r key value; do
  printf -v "$key" %s "$value" && export "$key"
done <.env

How Can I Execute Environment Variables in Shell Script?

Actually, you need to transform $i into the name of the variable, then read $varname. If the shell would support this, you should write cd $$i. Unfortunately, this will not work, because $$ gives the current PID.

As suggested by @Biffen, you should use shell variable substitution:

cd ${!i}

Previous answer, using dangerous eval instruction:

eval cd \$$i

Note: eval is a dangerous instruction. Use it only if you are sure of the content of your files (not files provided by untrusted users).

How to set child process' environment variable in Makefile

Make variables are not exported into the environment of processes make invokes... by default. However you can use make's export to force them to do so. Change:

test: NODE_ENV = test

to this:

test: export NODE_ENV = test

(assuming you have a sufficiently modern version of GNU make >= 3.77 ).

Set environment variables from file of key/value pairs

Problem with your approach is the export in the while loop is happening in a sub shell, and those variable will not be available in current shell (parent shell of while loop).

Add export command in the file itself:

export MINIENTREGA_FECHALIMITE="2011-03-31"
export MINIENTREGA_FICHEROS="informe.txt programa.c"
export MINIENTREGA_DESTINO="./destino/entrega-prac1"

Then you need to source in the file in current shell using:

. ./conf/prac1

OR

source ./conf/prac1

gnu makefile linux set environment variable in calling shell, is it possible?

Yeah, you cannot do that. It's a fundamental aspect of all Unix systems for 50 years that a child process cannot modify the environment of its parent. Make can do many things, but it cannot subvert that basic restriction.

Setting persistent environment variables between multiple `call`s in Rebol or Red on Windows

Regardless of what language one is using: at a plain mechanical API level--from a child process--it's not possible to set environment variables in the parent process:

https://stackoverflow.com/a/263068/211160

You can use SET-ENV to set the variables in the calling process, and the child process created by CALL will inherit them. In R3-Alpha on Linux:

>> set-env "FOO" "10"

>> call "echo $FOO"
10
== none

In Red on Windows:

>> set-env "FOO" "10"

>> call/shell/output "echo %FOO%" out: ""
== 0

>> out
== "10^/"

If you want environment variables to persist between child process calls, you could rig some protocol up where the child process returns information to the parent, that lets it make the SET-ENV modification for the next CALL to inherit.

Can I set an environment variable on Bash's command line?

Define the target of your shortcut file as follows:

C:\cygwin64\bin\mintty.exe /bin/bash -l -c "MSYSTEM=MINGW64 exec -l bash"

This command:

• invokes bash directly as a login shell (-l)
• passes it a command (-c) that defines the environment variable of interest (MSYSTEM=MINGW64) and then invokes a new copy of bash (exec -l bash), which inherits the existing environment, plus the new definition, but sources the profile(s) again, due to -l
  
  (and prepends - to the executable name reported in $0 (-bash), as would happen if you started Mintty with just -, which is what the regular Cygwin64 Terminal shortcut does).

---

An alternative is to set the environment variable in Windows first.

• [Not an option for the OP] If the environment variable should always have the same value, set it persistently as follows: run sysdm.cpl, go to the Advanced tab, click on Environment Variables... and define variable MSYSTEM as needed.

• To define the variable ad-hoc, create a batch file as follows and make the shortcut target that batch file:

  @echo off
  
  # Define the env. variable with the desired value.
  set "MSYSTEM=MINGW64"
  
  # Invoke Mintty with a login shell, which will now see the env. variable.
  # Adjust the path to mintty.exe as needed.
  c:\cygwin64\bin\mintty.exe -
  

Note: Opening the batch file from a shortcut briefly opens a regular console window before opening Mintty, which may be undesired.

A simple helper WSH script, as demonstrated in this answer of mine, can prevent this.

---

Related Topics