Lettere maiuscole corrette di script Bash e shell

193

Mi imbatto in molti script di shell con variabili in maiuscolo e ho sempre pensato che ci fosse un grave fraintendimento. La mia comprensione è che, per convenzione (e forse per necessità molto tempo fa), le variabili di ambiente sono in maiuscolo.

Ma nei moderni ambienti di scripting come Bash, ho sempre preferito la convenzione dei nomi minuscoli per le variabili temporanee e quelle maiuscole solo per le variabili esportate (ovvero l'ambiente) . Per esempio:

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

Questa è sempre stata la mia opinione sulle cose. Esistono fonti autorevoli che concordano o non sono d'accordo con questo approccio o è puramente una questione di stile?

— Jason Smith
fonte

262

Per convenzione, variabili ambientali ( PAGER, EDITOR, ...) e variabili shell interne ( SHELL, BASH_VERSION, ...) vengono capitalizzati. Tutti gli altri nomi di variabili devono essere in minuscolo.

Ricorda che i nomi delle variabili fanno distinzione tra maiuscole e minuscole; questa convenzione evita di sostituire accidentalmente le variabili ambientali e interne.

Rispettando questa convenzione, puoi stare certo che non è necessario conoscere tutte le variabili di ambiente utilizzate dagli strumenti o dalle shell UNIX per evitare di sovrascriverle. Se è la tua variabile, minuscola. Se lo esporti, mettilo in maiuscolo.

— lhunath
fonte

8

+1. Un buon punto per la sovrascrittura accidentale. Ho dimenticato di menzionarlo, ma ora che me lo dici, penso di aver deciso di usare le lettere minuscole perché ho letto o sentito parlare di quel problema.

— JasonSmith,

5

Ho pensato che la ragione principale per usare nomi di variabili maiuscole fosse evitare conflitti con i comandi della shell. Recentemente abbiamo avuto il nome host di uno dei nostri server accidentalmente cambiato in '=' perché uno script utilizzava una variabile 'nomehost'.

— ThisSuitIsBlackNon

25

@ThisSuitIsBlackNot Ignorando il codice scadente, le variabili hanno il prefisso con un dollaro quando vengono espanse e utilizzate in un luogo in cui non possono essere confuse con un nome di comando quando non lo sono. Ovviamente, fare hostname = moo ti metterà nei guai. Non perché stai utilizzando un "nome host" in lettere minuscole, ma perché non stai utilizzando la sintassi di assegnazione corretta. L'assegnazione viene eseguita con hostname = moo, senza spazi. Supponendo che il codice sia corretto, non è necessario preoccuparsi dei nomi delle variabili in conflitto con i nomi dei comandi.

— lhunath,

3

Tutti i libri di testo che ho visto sono sempre in maiuscolo per tutte le variabili della shell. Mentre sono ammessi nomi di variabili in minuscolo, la convenzione è in maiuscolo.

— Brian S. Wilson,

3

Non lo sapevo e ho perso solo un paio d'ore. usando USER="username"in uno script bash automatizzando alcuni comandi remoti su ssh anziché user="username". Ugh! Sono contento di saperlo ora!

— Gabriel Staples,

28

Qualsiasi convenzione di denominazione seguita in modo coerente sarà sempre di aiuto. Ecco alcuni suggerimenti utili per la denominazione delle variabili shell:

Utilizzare tutti i caratteri maiuscoli e minuscoli per le variabili e le costanti esportate, in particolare quando sono condivise tra più script o processi. Utilizzare un prefisso comune ogniqualvolta applicabile in modo che le variabili correlate si distinguano e non si scontrino con le variabili interne di Bash che sono tutte in maiuscolo.

Esempi:
- Variabili esportate con un prefisso comune: JOB_HOME JOB_LOG JOB_TEMP JOB_RUN_CONTROL
- costanti: LOG_DEBUG LOG_INFO LOG_ERROR STATUS_OK STATUS_ERROR STATUS_WARNING
Usa la "custodia del serpente" ( tutte minuscole e caratteri di sottolineatura ) per tutte le variabili che hanno come ambito un singolo script o un blocco.

Esempi: input_file first_value max_amount num_errors

Usa maiuscole / minuscole quando la variabile locale ha qualche relazione con una variabile d'ambiente, come: old_IFS old_HOME
Utilizzare un carattere di sottolineatura iniziale per variabili e funzioni "private". Ciò è particolarmente rilevante se si scrive mai una libreria di shell in cui le funzioni all'interno di un file di libreria o tra i file devono condividere le variabili, senza mai scontrarsi con qualsiasi cosa che possa essere nominata in modo simile nel codice principale.

Esempi: _debug _debug_level _current_log_file
Evitare la custodia del cammello . Ciò ridurrà al minimo i bug causati da errori di battitura. Ricorda, le variabili della shell fanno distinzione tra maiuscole e minuscole .

Esempi: inputArray thisLooksBAD, numRecordsProcessed,veryInconsistent_style

Guarda anche:

The Open Group Base Specificazioni Numero 7 - Variabili d'ambiente

— codeforester
fonte

1

Questa è una convenzione ma non è universalmente accettata. La logica contro il caso del cammello non è del tutto convincente. La raccomandazione di utilizzare SHOUTING per le variabili esportate è leggermente controversa.

— triplo

3

Non ho affermato che si tratta di una convenzione comunemente seguita. Ho visto che la maggior parte dei programmatori non pensa seriamente a seguire forti convenzioni negli script di shell e ha pensato di annotare i miei pensieri in base a ciò che ho fatto.

— codeforester

8

Se le variabili della shell verranno esportate nell'ambiente, vale la pena considerare che la definizione di variabile di ambiente POSIX (Edizione 7, edizione 2018) specifica:

I nomi delle variabili di ambiente utilizzati dalle utility nel volume Shell and Utilities di POSIX.1-2017 sono costituiti esclusivamente da lettere maiuscole, cifre e trattino basso ( _) dai caratteri definiti nel set di caratteri portatili e non iniziano con una cifra.

...

Lo spazio dei nomi delle variabili di ambiente che contiene lettere minuscole è riservato alle applicazioni. Le applicazioni possono definire qualsiasi variabile d'ambiente con nomi da questo spazio dei nomi senza modificare il comportamento delle utility standard.

— Anthony Geoghegan
fonte

6

Faccio quello che fai tu. Dubito che ci sia una fonte autorevole, ma sembra uno standard di fatto abbastanza diffuso.

— DRAEMON
fonte

1

Sono d'accordo. È perché ALL_CAPS è brutto, ma è bene far risaltare le VARIABILI AMBIENTALI essendo brutti.

— magro

1

Sono d'accordo con te sullo stile di programmazione, ma non sono assolutamente d'accordo sul fatto che sia molto diffuso! Gli script della shell sono una di quelle lingue secondarie che le persone imparano solo in modo informale, quindi mi sento come se tutti dicessero sempre LOCATION =cat /tmp/location.txt

— JasonSmith

@jhs - Ovviamente sono stato fortunato negli script della shell con cui ho dovuto lavorare!

— Draemon,

4

"Lo spazio dei nomi delle variabili di ambiente che contiene lettere minuscole è riservato alle applicazioni." - POSIX IEEE Std 1003.1-2008 sezione 8.1

— tripleee

5

In realtà, il termine "variabili d'ambiente" sembra essere di conio abbastanza recente. Kernighan e Pike nel loro libro classico "L'ambiente di programmazione UNIX", pubblicato nel 1984, parlano solo di "variabili shell" - non c'è nemmeno una voce per "ambiente" nell'indice!

8

Penso che sia un'omissione del libro. getenv (), setenv () e environment sono stati introdotti in UNIX versione 7 (1979).en.wikipedia.org/wiki/Version_7_Unix

— Juliano

3

Quel libro sembra notare che le variabili maiuscole hanno un significato speciale.

— Ashawley,

3

È solo una convenzione molto diffusa, dubito che esista una fonte "autorevole".

— Alnitak
fonte

1

tendo ad usare ALL_CAPS sia per l'ambiente che per le variabili globali. ovviamente, in Bash non esiste un reale ambito di variabili, quindi c'è una buona porzione di variabili usate come globali (principalmente impostazioni e tracciamento dello stato) e relativamente pochi "locali" (contatori, iteratori, stringhe parzialmente costruite e temporali)

— Javier
fonte

Sì, in un certo senso penso concettualmente alle variabili non esportate come locali, dal momento che Bash così spesso sta costringendo i processi figlio a fare tutto ciò che ha il compito di fare.

— JasonSmith,