Caracteres permitidos en nombres de variables de entorno Linux

¿Qué caracteres están permitidos en los nombres de variables de entorno de Linux? Mi búsqueda superficial de páginas de manual y la web solo produjo información sobre cómo trabajar con variables, pero no qué nombres están permitidos.

Tengo un programa Java que requiere una variable de entorno definida que contiene un punto, como com.example.fancyproperty. Con Windows puedo configurar esa variable, pero no tuve suerte configurándola en Linux (probado en SuSE y Ubuntu). ¿Se permite incluso ese nombre de variable?

Del grupo abierto :

Estas cadenas tienen la forma nombre = valor; los nombres no deben contener el carácter '='. Para que los valores sean portables en los sistemas que cumplen con IEEE Std 1003.1-2001, el valor debe estar compuesto por caracteres del conjunto de caracteres portátiles ( excepto NUL y como se indica a continuación ).

Por lo tanto, los nombres pueden contener cualquier carácter excepto = y NUL, pero:

Los nombres de las variables de entorno utilizados por las utilidades en el volumen Shell y Utilities de IEEE Std 1003.1-2001 consisten únicamente en letras mayúsculas, dígitos y el '_' (guión bajo) de los caracteres definidos en Portable Character Set y no comienzan con un dígito . Otros caracteres pueden ser permitidos por una implementación; las aplicaciones tolerarán la presencia de tales nombres.

Entonces, aunque los nombres pueden ser válidos, es posible que su shell no admita nada más que letras, números y guiones bajos.

La sección de estándares POSIX en shells de IEEE Std 1003.1-2008 / IEEE POSIX P1003.2 / ISO 9945.2 Shell y herramientas estándar no define la convención léxica para nombres de variables, sin embargo, una mirada superficial a la fuente revela que usa algo similar a

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

(Editar: Se agregó subrayado perdido en la segunda clase de caracteres).

Una nota rápida, ya que algunos shells no admiten el + en la expresión regular, una expresión regular potencialmente más portátil puede ser:

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

Mi prueba rápida mostró que básicamente siguen las mismas reglas que los nombres de variables C, es decir

1. az, AZ _y 0-9
2. NO puede comenzar con un número

Entonces esto excluye .dentro de ellos. Cualquier nombre de variable ilegal se acredita con unknown command.

Esto se probó en ZSH, que es principalmente compatible con BASH.

Depende de lo que quieras decir con 'permitido'.

Ignorando Windows para el nonce:

El entorno es una serie de cadenas, pasadas a la función principal de un programa. Si lee execve (2), no verá requisitos o límites en estas cadenas que no sean terminación nula.

Por convención, cada cadena consta de NOMBRE = valor. No existe una convención de citas, por lo que no puede tener un '=' en el nombre de esta convención.

Los humanos normales establecen estas cadenas discutiéndolas con su caparazón. Cada shell tiene sus propias ideas de lo que son variables NAME válidas, por lo que debe leer la página del manual del shell del momento para ver qué piensa.

En general, cosas como com.baseball.spit = fleagh son propiedades del sistema Java, y si algún programa Java está dispuesto a recurrir al entorno, es mejor especificarlos con -D.

Depende de la cáscara. Supongo que está usando bash de forma predeterminada, en cuyo caso se permiten letras, números y guiones bajos, pero no puede comenzar el nombre de la variable con un número. A partir de Bash v.3, no se permiten puntos dentro de los nombres de variables .

SI, PUEDES HACERLO.

Usa execy envordena para implementar esta escena.

Dispositivo de prueba en Docker

docker run -it --rm alpine:3.10

Ejecutar comando en contenedor:

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

Verifique las variables de entorno:

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 auxpara verificar que el PID no haya cambiado

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

Use pythonpara verificar la variable de entorno

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

SALIDA es happy-variable-name.

¿Qué ocurre?

1. Ejecutiva de llamada de Shell integrada
2. Ejecutar el intérprete de comandos integrado de shell syscall.exec crea el proceso 'env' para reemplazar el intérprete de comandos actual
3. proceso env llame a syscall.execvp cree el proceso '/ bin / sh' para reemplazar el proceso env

De otra manera

• Imagen de Docker

Si está usando docker, puede establecer variables en Dockerfile

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

• Kubernetes configmap

Si está utilizando kubernetes, puede configurar variables mediante 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

Implementar pod kubectl apply -f test.yaml

Verificar kubectl logs foobarsalida:

xx.ff-bar=1234

ConfigMap permite '-', '_' o '.'

Si bien la mayoría de los shell no permitirán establecer variables de entorno (como se menciona en otras respuestas), si lo necesita, puede ejecutar otros programas con variables de entorno no estándar utilizando env(1).

Por ejemplo, borrar todo el entorno y establecer el Strange.Env:Varvalor foo, y ejecutar el programa perl que lo imprime:

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

imprimirá

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