bash script and local env variable namespace collision

Shell variables are initialised from environment variables in every shell, you can't get around that.

When the shell starts, for every environment variable it receives that has a valid name as a shell variable, the shell assigns the corresponding shell variable the corresponding value. For instance, if your script is started as:

env VAR_A=xxx your-script

(and has a #!/bin/bash - she-bang), env will execute /bin/bash and pass VAR_A=xxx to that bash command, and bash will assign its $VAR_A variable the value xxx.

In the Bourne shell and in the C-shell, if you assign a new value to that shell variable, it doesn't affect the corresponding env variable passed to later commands executed by that shell, you have to use export or setenv for that (note however that in the Bourne shell if you unset a variable, it removes both the shell variable and environment variable).

In:

env VAR=xxx sh -c 'VAR=yyy; other-command'

(with sh being the Bourne shell, not modern POSIX shells) Or:

env VAR=xxx csh -c 'set VAR = yyy; other-command'

other-command receives VAR=xxx in its environment, not VAR=yyy, you'd need to write it:

env VAR=xxx sh -c 'VAR=yyy; export VAR; other-command'

or

env VAR=yyy csh -c 'setenv VAR yyy; other-command'

For other-command to receive VAR=yyy in its environment.

However, ksh (and POSIX as a result, and then bash and all other modern Bourne-like shells as a result) broke that.

Upon start-up those modern shells bind their shell variable to the corresponding environment variable.

What that means is that a script may clobber the environment just by setting one of its variables even if it doesn't export it. Some shells are even known to remove the environment variables it cannot map to shell variables (which is why it's recommended to only use shell-mappable variable names for environment variable names).

That's a main reason why by convention, all uppercase variables should be reserved for environment variables.

To work around that, if you want the commands executed by your script to receive the same environment as the shell interpreting your script received, you'd need to store that environment somehow. You can do it by adding:

my_saved_env=$(export -p)

at the start of your script, and then run your commands with:

(eval "$my_saved_env"; exec my-other-command and its args)

In the bosh and mksh shells, local variables in functions don't clobber environment variables (as long as you don't export them), though note that shell builtins which use some special variables (like HOME for cd, PATH for executable lookup...) would use the value of the shell (local) variable, not the environment one.

$ env VAR=env mksh -c 'f() { local VAR=local; echo "$VAR"; printenv VAR; }; f'
local
env

You could make the variable VAR_A read only by adding a line:

readonly VAR_A

at the top of your script. This would cause the value of VAR_A to be preserved as per your local environment.

readonly: readonly [-aAf] [name[=value] ...] or readonly -p

Mark shell variables as unchangeable.

Mark each NAME as read-only; the values of these NAMEs may not be
changed by subsequent assignment.  If VALUE is supplied, assign VALUE
before marking as read-only.

Options:
  -a        refer to indexed array variables
  -A        refer to associative array variables
  -f        refer to shell functions
  -p        display a list of all readonly variables and functions

An argument of `--' disables further option processing.

Exit Status:
Returns success unless an invalid option is given or NAME is invalid.

The following example should make it clear:

$ export FOO="somevalue"        # environment variable FOO set to somevalue
$ cat test                      # test script
echo $FOO                       # print the value of FOO
readonly FOO                       # set FOO to local
FOO="something"                 # attempt to modify FOO
echo $FOO                       # print the value of FOO -- you would see the value that was inherited from the environment
$ bash test
somevalue
test: line 3: FOO: readonly variable
something

If you want to print local variable VAR_A, you must call in its local scope, otherwise, it will print value of global variable VAR_A:

#! /bin/bash 

VAR_A="I'm global"

function lexical() {
    local VAR_A="I'm lexical"
    echo $VAR_A
}

echo -n "Global VAR_A: "
echo $VAR_A
echo -n "Lexical VAR_A: "
lexical

Run it:

$ ./test.sh 
Global VAR_A: I'm global
Lexical VAR_A: I'm lexical

You can read more about local in bash from man page:

local [option] [name[=value] ...]
              For each argument, a local variable named name is  created,  and
              assigned  value.   The option can be any of the options accepted
              by declare.  When local is used within a function, it causes the
              variable  name  to have a visible scope restricted to that func‐
              tion and its children.  With no operands, local writes a list of
              local  variables  to the standard output.  It is an error to use
              local when not within a function.  The return status is 0 unless
              local  is  used outside a function, an invalid name is supplied,
              or name is a readonly variable.