Poprawna wielkość liter w zmiennych skryptu Bash i powłoki

Natrafiam na wiele skryptów powłoki ze zmiennymi we wszystkich wielkich literach i zawsze myślałem, że istnieje poważne nieporozumienie z tym. Rozumiem, że zgodnie z konwencją (a być może z konieczności dawno temu) zmienne środowiskowe są pisane wielkimi literami.

Ale w nowoczesnych środowiskach skryptowych, takich jak Bash, zawsze wolałem konwencję nazw małych liter dla zmiennych tymczasowych i wielkich liter tylko dla eksportowanych zmiennych (tj. Środowiskowych) . Na przykład:

#!/usr/bin/env bash
year=`date +%Y`
echo "It is $year."
export JAVA_HOME="$HOME/java"

To zawsze było moje zdanie na ten temat. Czy są jakieś wiarygodne źródła, które zgadzają się lub nie zgadzają z tym podejściem, czy jest to wyłącznie kwestia stylu?

Umownie, zmiennych środowiskowych ( PAGER, EDITOR...) oraz wewnętrznych zmiennych powłoki ( SHELL, BASH_VERSION...) są aktywowane. Wszystkie pozostałe nazwy zmiennych powinny być pisane małymi literami.

Pamiętaj, że w nazwach zmiennych rozróżniana jest wielkość liter; Konwencja ta pozwala uniknąć przypadkowego zastąpienia zmiennych środowiskowych i wewnętrznych.

Trzymając się tej konwencji, możesz mieć pewność, że nie musisz znać każdej zmiennej środowiskowej używanej przez narzędzia UNIX lub powłoki, aby uniknąć ich zastąpienia. Jeśli jest to twoja zmienna, wpisz ją małymi literami. Jeśli go eksportujesz, wielkie litery.

Wszelkie konsekwentnie przestrzegane konwencje nazewnictwa zawsze pomogą. Oto kilka pomocnych wskazówek dotyczących nazewnictwa zmiennych powłoki:

• Użyj wszystkich wielkich liter i znaków podkreślenia dla eksportowanych zmiennych i stałych, zwłaszcza gdy są one współużytkowane przez wiele skryptów lub procesów. W stosownych przypadkach używaj wspólnego przedrostka, aby pokrewne zmienne wyróżniały się i nie kolidowały ze zmiennymi wewnętrznymi Bash, które są dużymi literami.

  Przykłady:

  • Wyeksportowane zmienne ze wspólnym prefiksem: JOB_HOME JOB_LOG JOB_TEMP JOB_RUN_CONTROL
  • Stałe: LOG_DEBUG LOG_INFO LOG_ERROR STATUS_OK STATUS_ERROR STATUS_WARNING

• Użyj „węża” ( wszystkie małe i podkreślenia ) dla wszystkich zmiennych, których zakres obejmuje pojedynczy skrypt lub blok.

  Przykłady: input_file first_value max_amount num_errors

  Użyj zmiennej mieszanej, gdy zmienna lokalna ma jakiś związek ze zmienną środowiskową, na przykład: old_IFS old_HOME

• Użyj wiodącego podkreślenia dla „prywatnych” zmiennych i funkcji. Jest to szczególnie istotne, jeśli kiedykolwiek napiszesz bibliotekę powłoki, w której funkcje w pliku biblioteki lub między plikami muszą współdzielić zmienne, bez kolizji z czymkolwiek, co mogłoby być podobnie nazwane w głównym kodzie.

  Przykłady: _debug _debug_level _current_log_file

• Unikaj futerału wielbłąda . Pozwoli to zminimalizować błędy spowodowane literówkami. Pamiętaj, że w zmiennych powłoki rozróżniana jest wielkość liter .

  Przykłady: inputArray thisLooksBAD, numRecordsProcessed,veryInconsistent_style

Zobacz też:

• Podstawowa specyfikacja grupy otwartej Wydanie 7 - Zmienne środowiskowe

Jeśli zmienne powłoki mają zostać wyeksportowane do środowiska, warto wziąć pod uwagę, że POSIX (wydanie 7, wydanie 2018) Definicja zmiennej środowiskowej określa:

Nazwy zmiennych środowiskowych używane przez narzędzia w tomie Shell and Utilities POSIX.1-2017 składają się wyłącznie z wielkich liter, cyfr i podkreślenia ( _) ze znaków zdefiniowanych w przenośnym zestawie znaków i nie zaczynają się od cyfry.

...

Przestrzeń nazw nazw zmiennych środowiskowych zawierających małe litery jest zarezerwowana dla aplikacji. Aplikacje mogą definiować dowolne zmienne środowiskowe o nazwach z tej przestrzeni nazw bez modyfikowania zachowania standardowych narzędzi.

Robię to co ty. Wątpię, by istniało wiarygodne źródło, ale wydaje się ono dość powszechnym de facto standardem.

W rzeczywistości termin „zmienne środowiskowe” wydaje się mieć dość nowy termin. Kernighan i Pike w swojej klasycznej książce „The UNIX Programming Environment”, wydanej w 1984 r., Mówią tylko o „zmiennych powłoki” - w indeksie nie ma nawet hasła „środowisko”!

Jest to po prostu bardzo szeroko stosowana konwencja, wątpię, by było dla niej „wiarygodne” źródło.

Zwykle używam ALL_CAPS zarówno dla zmiennych środowiskowych, jak i globalnych. oczywiście w Bash nie ma rzeczywistego zakresu zmiennych, więc jest duża część zmiennych wykorzystywanych jako globale (głównie ustawienia i śledzenie stanu) oraz stosunkowo niewiele „locals” (liczniki, iteratory, częściowo skonstruowane łańcuchy i tymczasowe)