To remove an environment variable, run
unset ALL_PROXY
Note that an environment variable only takes effect in a program and the program it launches. If you set an environment variable in one shell window, it doesn't affect other shell windows.
If you've added export ALL_PROXY=…
to an initialization file, remove it from there.
You can run export
with no arguments to see what environment variables are set in the current shell.
Remember that to make a shell variable available to the programs started by that shell, you need to export it, either by running export VAR
after the assignment VAR=VALUE
or by combining the two (export VAR=VALUE
).
JIM=x
JIM=20 nice -n 10 echo $JIM
does pass the JIM=20
environment variable to nice
, but it's not nice
nor echo
that expands $JIM
, that's the shell.
The shell forks a process and executes:
execve("/usr/bin/nice", ["nice", "-n", "10", "echo", "x"], ["JIM=20", other vars])
nice
sets the niceness and then executes in the same process:
execve("/bin/echo", ["echo", "x"], ["JIM=20", other vars])
So echo
does receive JIM=20
in its environment, but echo
doesn't do anything with its environment.
Had you run:
JIM=20 nice -n 10 sh -c 'echo $JIM'
Then sh
would have done something with that environment variable. Shells map the environment variables they receive to shell variables. So above, that sh
would have set its $JIM
variable to 20
and called its echo
builtin with 20
as argument.
Best Answer
Other than with the
-i
option, which wipes the whole environment, POSIXenv
doesn't provide any way to unset a variable.However, with a few
env
implementations (including GNU's,busybox
' and FreeBSD's at least), you can do:Which would work at removing every instance of an
ENV_VAR
variable from the environment (note though that it doesn't work for the environment variable with an empty name (env -u ''
either gives an error or is ineffective depending on the implementation even though all acceptenv '=value'
, probably a limitation incurred by theunsetenv()
C function which POSIX requires to return an error for the empty string, while there's no such limitation forputenv()
)).Portably (in POSIX shells), you can do:
(note that with some shells, using
exec
can change whichcommand
is run: runs the one in the filesystem instead of a function or builtin for instance (and would bypassalias
expansion obviously), likeenv
above. You'd want to omit it in those cases).But that won't work for environment variables that have a name that is not mappable to a shell variable (note that some shells like
mksh
would strip those variables from the environment on startup anyway), or variables that have been marked read-only.-v
is for the Bourne shell andbash
whoseunset
without-v
could unset aENV_VAR
function if there was no variable by that name. Most other shells wouldn't unset functions unless you pass the-f
option. (unlikely to make a difference in practice).(Also beware of the bug/misfeature of
bash
/mksh
/yash
whoseunset
, under some circumstance may not unset the variable, but reveal the variable in an outer scope)If
perl
is available, you could do:Which will work even for the environment variable with an empty name.
Now all those won't work if you want to change an environment variable for a builtin or function and don't want them to run in a subshell, like in
bash
:(here unsetting LANG as a misguided approach at making sure
.
is used and understood as the decimal separator. It would be better to useLC_ALL=C printf...
for that)With some shells, you can instead create a local scope for the variable using a function:
With
zsh
, you can also use an anonymous function:That approach won't work in some shells (like the ones based on the Almquist shell), whose
local
don't declare the variable as initially unset (but inherit the value and attributes). In those, you can dolocal ENV_VAR; unset ENV_VAR
, but don't do that inmksh
oryash
(typeset
instead oflocal
for that one) as that wouldn't work, theunset
would only be cancelling thelocal
.¹ Also beware that in
bash
, the localENV_VAR
(even though unset) would retain the export attribute. So ifcommand
was a function that assigns a value toENV_VAR
, the variable would be available in the environment of commands called afterwards.unset ENV_VAR
would clear that attribute. Or you could uselocal +x ENV_VAR
which would also ensure a clean slate (unless that variable has been declared read-only, but then there's nothing you can do about it inbash
).