Allowed characters in Linux environment variable names

The POSIX standards on shells section of IEEE Std 1003.1-2008 / IEEE POSIX P1003.2/ISO 9945.2 Shell and Tools standard doesn't define the lexical convention for variable names, however a cursory look at the source reveals it uses something similar to

[a-zA-Z_]+[a-zA-Z0-9_]*

(Edit: Added missing underscore in 2nd character class.)

A quick note, as some shells don't support the + in regex, a potentially more portable regex may be:

[a-zA-Z_]{1,}[a-zA-Z0-9_]{0,}

My quick testing showed that they basically follow the same rules as C variable names do have, namely

1. a-z, A-Z, _ and 0-9
2. May NOT begin with a number

So this excludes . inside them. Any illegal variable name is credited with unknown command.

This was tested in ZSH, which is mostly BASH-compatible.

YES, YOU CAN DO IT.

Use exec and env command to implement this scene.

Test Fixture in Docker

docker run -it --rm alpine:3.10 

Run command in container:

exec env spring.application_name=happy-variable-name ${SHELL:-/bin/sh} 

Verify environment variables:

HOSTNAME=bd0bccfdc53b SHLVL=2 HOME=/root spring.application_name=happy-variable-name TERM=xterm PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin PWD=/ 

Use ps aux to verify PID not changed

PID USER TIME COMMAND 1 root 0:00 /bin/sh 12 root 0:00 ps aux 

Use python to verify environemnt variable

apk add python python -c 'import os; print(os.environ["spring.application_name"])' 

OUTPUT is happy-variable-name.

What happen?

1. Shell call builtin exec
2. Shell builtin exec call syscall.exec create process 'env' to replace current shell
3. env process call syscall.execvp create process '/bin/sh' to replace env process

Another way

• Docker image

If you are using docker, you can set variable in Dockerfile

FROM busybox ENV xx.f%^&*()$#ff=1234 

• Kubernetes configmap

If you are using kubernetes, you can set variable by ConfigMap

test.yaml

apiVersion: v1 kind: ConfigMap metadata: name: foo-config data: "xx.ff-bar": "1234" --- apiVersion: v1 kind: Pod metadata: name: foobar spec: containers: - name: test-container image: k8s.gcr.io/busybox command: [ "/bin/sh", "-c", "env" ] envFrom: - configMapRef: name: foo-config restartPolicy: Never 

Deploy pod kubectl apply -f test.yaml

Verify kubectl logs foobar output:

xx.ff-bar=1234 

ConfigMap allow '-', '_' or '.'

Depends on what you mean by 'allowed'.

Ignoring Windows for the nonce:

The environment is an array of strings, passed to the main function of a program. If you read execve(2), you will see no requirements or limits on these strings other than null-termination.

By convention, each string consists of NAME=value. There is no quoting convention, so you can't have an '=' in the name in this convention.

Normal humans set these strings by discussing them with their shell. Each shell has it's own ideas of what are valid variable NAMEs, so you have to read the man page for the shell-of-the-moment to see what it thinks.

Generally, things like com.baseball.spit=fleagh are Java system properties, and whether or not some Java program is willing to fall back to the environment, it's better to specify them with -D.

It depends on the shell. I'm guessing you're using bash by default, in which case letters, numbers and underscores are allowed, but you can't start the variable name with a number. As of Bash v.3, periods are not allowed within variable names.

While most shell will not allow setting enviroment variables (as mentioned in other answers), if you have need you can execute other programs with nonstandard enviroment variables using env(1).

For example, erasing all enviroment and setting Strange.Env:Var to value foo, and executing perl program that prints it:

env -i Strange.Env:Var=foo perl -MData::Dumper -E 'say Dumper(\%ENV)' 

will print

$VAR1 = { 'Strange.Env:Var' => 'foo' };