2012-11-15 10 views
7

È buona pratica di programmazione di shell utilizzare le variabili di sola lettura laddove possibile o presenta degli svantaggi? Per esempio. se volevo scrivere qualche script che è costituito da più file di script che fanno uso di percorsi di file immutabili, avrebbe senso di dichiarare i percorsi del genere:Uso di variabili di sola lettura negli script di shell

readonly LOGS 
export LOGS 
LOGS="/some/path" 

Un'altra domanda: E 'una buona idea di dividere monolitica e anche noioso leggere il codice dello script di shell in file separati? Mille grazie per le vostre risposte.

+1

Finora, non ho visto alcun da bash che sarebbe buona pratica di programmazione. Se vuoi imparare uno script di shell pulito, rimani semplicemente con 'sh'. Ciò che non può essere fatto facilmente in questo modo, non dovrebbe essere fatto con bash. –

+0

Le variabili di sola lettura possono essere utili per motivi di sicurezza. Per capire perché, imposta una variabile readonly sulla riga di comando e poi vedi quanto è difficile provare a cambiarla: l'ultima volta che ti ho controllato devi hackerare Bash con un debugger (es. 'Gbd attach ') per poter cambia un valore variabile di sola lettura. –

+0

@ A.Danischewski - o avvia semplicemente un nuovo processo shell. –

risposta

11

Suona come si potrebbe pensare che readonly fa più di quanto davvero. Per prima cosa, lo stato di sola lettura non viene esportato nell'ambiente o ereditato dai processi figli:

$ declare -rx LOGS=hello 
$ LOGS=goodbye 
bash: LOGS: readonly variable 
$ bash -c 'echo "$LOGS"' 
hello 
$ bash -c 'LOGS=goodbye; echo "$LOGS"' 
goodbye 
$ 
+0

punto eccellente, ma si potrebbe facilmente aggirare usando "." invece di chiamare lo script come processo figlio. – figtrap

4

In generale, l'utilizzo di variabili di sola lettura (in qualsiasi lingua) e la modularizzazione del programma (in qualsiasi lingua) è una buona cosa.

Leggere solo le variabili proteggono da una fonte comune di errori e consente di migliorare la leggibilità e la gestibilità. Sapere che puoi contare sul valore di una variabile ti consente di ragionare meglio sul tuo programma e di fare ipotesi su quella variabile in un secondo momento, cose che non potresti fare se la variabile fosse mutabile.

La modularizzazione migliora la manutenibilità e la riutilizzabilità. Più moduli generalmente significa più unità a grana fine che possono trovare riutilizzo in circostanze diverse, codice più breve che è più facile da leggere e, se i tuoi moduli sono indipendenti, meno interazioni tra le parti che potrebbero distruggere una modifica.

3

Non credo che le variabili di sola lettura in bash siano utili. Non riesco a pensare a nessun problema che ho visto che avrebbe potuto essere prevenuto rendendo una variabile di sola lettura. Tali limiti vanno contro la natura dinamica di bash. Esistono altre cause più comuni di problemi (come i mispelling o la dimenticanza di dichiarare variabili come locali) che sono impossibili da prevenire in ogni caso.

Se si desidera dividere le cose, provare a dividere solo "funzioni", non solo blocchi di codice. È più facile riutilizzare una piccola cosa se sai che "source ~/myscript.sh" in realtà non fa nulla.

+1

Grazie. Ma le variabili di sola lettura non hanno svantaggi, vero? – user1812379

+3

In realtà le variabili di sola lettura hanno il loro valore. Se mantieni decine di script che sono cross-sourced allora contrassegnare una variabile come immutabile ha molto senso!Come @MarkReed ha menzionato che non sono davvero immutabili, ma quando qualcun altro inizia a leggere le tue "cose" avranno intenzione che questa variabile non sia destinata a cambiare! Questo è veramente utile e rende gli script molto più leggibili. Credo davvero che la condivisione di uno stato in variabili globali sia una pratica terribile, ma come sappiamo tutti bash non è stato progettato pensando a questo. – egelev

4

Un uso classico di variabili di sola lettura è con TMOUT. Impostando questa variabile su un valore diverso da zero, si effettuerà il logout di una sessione terminale interattiva dopo TMOUT secondi di inattività (ovvero nessun input da tastiera). Per sconfiggere un utente intelligente di ignorare l'impostazione, utilizzare readonly:

readonly TMOUT=60 

Dopo aver fatto questo, non v'è alcun modo per farlo:

export TMOUT=0 
+0

Facilmente lavorato con 'exec bash'. Con '--norc' se necessario per evitare che' TMOUT' venga nuovamente impostato. –