Dozwolone znaki w nazwach zmiennych środowiskowych Linux

Jakie znaki są dozwolone w nazwach zmiennych środowiskowych systemu Linux? Moje pobieżne przeszukiwanie stron podręcznika systemowego i sieci dostarczyło jedynie informacji o tym, jak pracować ze zmiennymi, ale nie o tym, które nazwy są dozwolone.

Mam program Java, który wymaga zdefiniowanej zmiennej środowiskowej zawierającej kropkę, na przykład com.example.fancyproperty. W systemie Windows mogę ustawić tę zmienną, ale nie udało mi się ustawić jej w Linuksie (próbowałem w SuSE i Ubuntu). Czy ta nazwa zmiennej jest w ogóle dozwolona?

Z The Open Group :

Te ciągi mają postać nazwa = wartość; nazwy nie mogą zawierać znaku „=”. Aby wartości mogły być przenoszone między systemami zgodnymi ze standardem IEEE 1003.1-2001, wartość powinna składać się ze znaków z przenośnego zestawu znaków ( z wyjątkiem NUL i jak wskazano poniżej ).

Nazwy mogą więc zawierać dowolny znak z wyjątkiem = i NUL, ale:

Nazwy zmiennych środowiskowych używane przez programy narzędziowe w tomie Shell and Utilities normy IEEE Std 1003.1-2001 składają się wyłącznie z wielkich liter, cyfr i znaku „_” (podkreślenia) ze znaków zdefiniowanych w Portable Character Set i nie zaczynają się od cyfry . Implementacja może zezwolić na inne znaki; wnioski będą tolerować obecność takich nazw.

Więc chociaż nazwy mogą być prawidłowe, twoja powłoka może nie obsługiwać niczego poza literami, cyframi i podkreśleniami.

Sekcja standardów POSIX dotyczących powłok w IEEE Std 1003.1-2008 / IEEE POSIX P1003.2 / ISO 9945.2 Standard powłoki i narzędzi nie definiuje konwencji leksykalnej dla nazw zmiennych, jednak pobieżne spojrzenie na źródło ujawnia, że ​​używa czegoś podobnego do

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

(Edycja: Dodano brakujące podkreślenie w 2. klasie znaków.)

Krótka uwaga, ponieważ niektóre powłoki nie obsługują + w wyrażeniu regularnym, potencjalnie bardziej przenośnym wyrażeniem regularnym może być:

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

Moje szybkie testy pokazały, że zasadniczo przestrzegają tych samych reguł, co nazwy zmiennych w C, a mianowicie

1. az, AZ _i 0-9
2. NIE MOŻE zaczynać się od liczby

Więc to wyklucza .ich wewnątrz. Każda niedozwolona nazwa zmiennej jest przypisywana unknown command.

Zostało to przetestowane w ZSH, który jest w większości kompatybilny z BASH.

Zależy od tego, co rozumiesz przez „dozwolone”.

Ignorowanie Windows na zawsze:

Środowisko to tablica ciągów przekazywana do głównej funkcji programu. Jeśli przeczytasz execve (2), nie zobaczysz żadnych wymagań ani ograniczeń dotyczących tych ciągów innych niż zakończenie zerowe.

Zgodnie z konwencją, każdy ciąg składa się z NAZWA = wartość. Nie ma konwencji cytowania, więc nie możesz mieć znaku „=” w nazwie w tej konwencji.

Normalni ludzie ustalają te warunki, omawiając je ze swoją skorupą. Każda powłoka ma swoje własne pomysły na temat prawidłowych zmiennych NAME, więc musisz przeczytać stronę podręcznika dla powłoki chwili, aby zobaczyć, co o tym myśli.

Ogólnie rzecz biorąc, rzeczy takie jak com.baseball.spit = fleagh są właściwościami systemowymi Javy i niezależnie od tego, czy jakiś program Java chce wrócić do środowiska, lepiej jest określić je za pomocą -D.

To zależy od powłoki. Domyślam się, że używasz basha domyślnie, w którym to przypadku litery, cyfry i podkreślenia są dozwolone, ale nie możesz rozpocząć nazwy zmiennej liczbą. Od wersji Bash v.3 kropki nie są dozwolone w nazwach zmiennych .

TAK, MOŻESZ TO ZROBIĆ.

Użyj execienv polecenie, aby zaimplementować tę scenę.

Testuj urządzenie w Dockerze

docker run -it --rm alpine:3.10

Uruchom polecenie w kontenerze:

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

Sprawdź zmienne środowiskowe:

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=/

Służy ps auxdo sprawdzania, czy PID nie został zmieniony

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

Służy pythondo weryfikacji zmiennej środowiskowej

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

OUTPUT jest happy-variable-name .

Co się stało?

1. Wywołanie wbudowanej powłoki exec
2. Wbudowane wywołanie exec w powłoce syscall.exec tworzy proces „env” w celu zastąpienia bieżącej powłoki
3. proces env wywołaj syscall.execvp utwórz proces '/ bin / sh', aby zastąpić proces env

Inny sposób

• Obraz platformy Docker

Jeśli używasz Dockera, możesz ustawić zmienną w Dockerfile

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

• Mapa konfiguracji Kubernetes

Jeśli używasz kubernetes, możesz ustawić zmienną za pomocą 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

Wdróż pod kubectl apply -f test.yaml

Sprawdź kubectl logs foobarwyjście:

xx.ff-bar=1234

ConfigMap zezwala na „-”, „_” lub „.”

Podczas gdy większość powłok nie pozwala na ustawienie zmiennych środowiskowych (jak wspomniano w innych odpowiedziach), jeśli potrzebujesz, możesz uruchomić inne programy z niestandardowymi zmiennymi środowiskowymi używając env(1) .

Na przykład, wymazanie całego środowiska i ustawienie Strange.Env:Varna wartość foooraz wykonanie programu w Perlu, który je drukuje:

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

wydrukuje

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