Bash – Safely define an environment variable

bashenvironment-variablesgnuvariable

AFAICT, neither GNU Bash, nor any other relevant package (e.g. GNU coreutils) that is commonly available in GNU/Linux distros, has a ready-made way to define an environment variable such that the attempt will fail, and indicate failure, if the environment variable already exists. Essentially, a "no-clobber" option for variable assignment, with a non-zero exit status on failure.

Shell parameter expansion (aka "parameter substitution") approaches avoid clobbering, but do not report failure:

unset MY_VARIABLE
: ${MY_VARIABLE:='my_value'}
: ${MY_VARIABLE:='this_will_fail_but_will_nevertheless_have_exit_code_0'}
echo $?
0
echo $MY_VARIABLE
my_value

The best workaround I have come up with is to create a function ("safedef") for that purpose:

die() {
    echo -e >&2 "$@"
    exit 1
}

safedef() {
    if [ -v $1 ]; then
        die 'Name conflict. Variable already defined. Will not overwrite it.'
    else
        # Create and assign environment variable
        export $1="${*:2}"
    fi
}

safedef MY_VARIABLE 'my_value'
safedef MY_OTHER_VARIABLE 'my_other_value'
# Etc, etc...

Questions:

Have I overlooked a ready-made way to achieve this, provided by a free software package that is available in some or all mainstream GNU/Linux distros?
Have I overlooked some kind of bug in safedef that means it could well unexpectedly fail to work as intended? (If so, what is the bug, and what might be a better approach?)

Best Answer

In bash I found the following:

unset MY_VARIABLE
: ${MY_VARIABLE='my_value'}
MY_VARIABLE=${MY_VARIABLE:+$( false )}${MY_VARIABLE:-'this_will_fail_with_exit_1'}
echo $?
echo $MY_VARIABLE

This prints:

1
my_value

Related Solutions

Bash Variables – Difference Between Environment Variable and Shell Variable

Your second assignment TEST="SHELL_TEST" doesn't un-export the variable. It's still marked as "to be inherited by children". And the value inherited by the child is the value currently set in the parent.
In other words, your second assignment doesn't revert the status of TEST to a shell variable, it's still an environment variable according to that terminology.

You'd have to un-export it for it to become unset in children processes:

$ typeset +x TEST
$ sh -c 'echo $TEST'

$

Shell – Define variables with a variable name

A variable assignment has the form of a variable name, followed by the equal sign, followed by the (optional) value.

This is a valid assignment:

ABC=123

"$x"1=1 is not a valid assignment, because "$x"1 is not a variable name. It may be evaluated to a variable name, but it isn't. The shell, in fact, believes it is a command.

One way for doing what you want to achieve is this:

eval "$x"1=1

Another way in bash (but not in other shells) is:

declare "$x"1=1

Or also (again bash-only):

let "$x"1=1

(There is no much difference in your case.)

But, as Jakuje noted in the comments, you probably want to go with arrays, if your shell has them (ksh, bash or zsh).

For completeness:

eval executes arbitrary commands. So, if on the right side of the equal sign you have a variable that expands to some command, that command will be executed. The following code:
```
x=a
y='$(echo hello)'
eval "$x=$y"
```
is equivalent to a=hello.
declare is a bash builtin to assign variables and won't execute any command. The following code:
```
x=a
y='$(echo hello)'
declare "$x=$y"
```
is equivalent to a='$(echo hello)'.
let is similar to declare, in that it doesn't execute commands. But contrary to declare, let may be used for arithmetic operations:
```
let a="1 + 2"
```
is equivalent to a=3.

Questions:

Best Answer

Related Solutions

Bash Variables – Difference Between Environment Variable and Shell Variable

Shell – Define variables with a variable name

Related Question