Newsgroup: it.comp.os.linux.iniziare
Titolo: bash: evitare conflitti tra variabili d'ambiente omonime

export COMMAND='my-command-test'
 
Però la variabile COMMAND potrebbe essere già stata definita (esportata) 
ed usata per *altri* determinati scopi...
 
Io invece l'ho appena sovrascritta, e questo potrebbe avere conseguenze 
(belle e brutte).
 
Per evitare questo pericolo, ho pensato di usare una mia convenzione:
 
# Convenzione:
#  - Nome in minuscolo.
#  - Uso di un token, cioè di un prefisso personalizzato (my4671_).
export my4671_command='my-command-test'
 
Così nel 99% dei casi non ci dovrebbero essere **sabotaggi*" accidentali.
 
Cosa ne pensate?
Non esistono standard ufficiali per evitare 
collisioni/interferenze/omonimie?

 collisioni/interferenze/omonimie?
 
No che io sappia.  Per la mia esperienza, alcuni programmi per evitare 
le collisioni usano <NOMEPROG>_<VARIABILE>
 
Ciao
Giovanni
-- 
   A computer is like an air conditioner,
   it stops working when you open Windows.
   < 
http://giovanni.homelinux.net/
 >

 dove viene definita.
 
????


Se definisci una variabile in uno script e la esporti quella variabile 
assume un valore solo all'interno dello script (e per i processi 
eseguiti all'interno) e solo fintanto che lo script è in esecuzione.


 Cosa ne pensate?
 
diciamo che è questione di lana caprina.
le variabili che imposti nel tuo script sono confinate alla shell che lo 
esegue ed eventualmente ai sottoprocessi che avvia, quindi alla fine sei 
te e nessun altro che le usa. 
 
se si parla invece di manutenibilità il discorso è diverso; è chiaro che 
se in uno script ridefinisci la variabile HOME la volta che qualcuno ci 
metterà le mani ti tirerà dietro i peggio insulti, compreso se questo 
"qualcuno" sei tu medesimo.

 Giovanni
 
Ora si capisce :)

 
 
Chi ci mette le mani deve conoscere lo strumento che sta usando, e tutti 
gli eventuali aggiornamenti/sviluppi/modifiche/bugs/controindicazioni.
Comunque non hai capito, come già detto, io mi riferisco alle 
assegnazioni fatte direttamente nel terminale, non dall'interno di 
qualche script.
 
Tanto per restare in tema, la variabile $HOME potrebbe anche essere 
intesa come home page, e non è scontato che tutti sappiano che contiene 
il nome della directory dell'utente.
Per cui qualche novellino potrebbe (dal suo terminale) dare un comando 
di questo tipo:
 
export HOME=
http://www.io.com
 
 
e da qui in poi, tutti gli strumenti (i **tools** di cui avevo 
accennato: funzioni globali, script, librerie, ecc.) che useranno questa 
variabile, potrebbero funzionare in modo improprio.

 variabile, potrebbero funzionare in modo improprio.
 
E quindi ti rendi conto del perche`
sarebbe meglio evitare il problema
all'origine.
 
E vi sono anche soluzioni standard...
 
bye,
 
-- 
 
piergiorgio

 E vi sono anche soluzioni standard...
 
????

 ????
 
File di configurazione, source(d) negli script.
Il path di tale file puo` facilmente essere
univoco (tutto il path).
 
Parametri a linea di comando (vedi getopt).
 
bye,
 
-- 
 
piergiorgio

 variabile, potrebbero funzionare in modo improprio.
 
sì, comunque limitatamente a quella shell però. se apre un altro 
terminale, se va su un altro programma o lancia un'altra sessione di bash 
la modifica non si vedrebbe.
 

 Parametri a linea di comando (vedi getopt).
 
Anche qui sono d'accordo.

 la modifica non si vedrebbe.
 
Però non è proprio così, se ad esempio, le esportazioni delle variabili 
d'ambiente (come $PATH, ecc.) sono permanenti (cioè dichiarate nel file 
~/.profile).
Correggimi se sbaglio.

 Correggimi se sbaglio.
 
non ti resta che provare. 
 
1 - apri un terminale
2 - modifica la variabile PATH
3 - apri un'altra finestra terminale
4 - digita 'echo $PATH'
 
se non la vedi modificata vuol dire che è come dico io.
 
il ~/.profile è uno script che viene letto ed eseguito ad ogni avvio di 
una nuova shell, sia terminale che per esecuzione di uno script. quindi 
ad ogni shell che avvii viene inizializzata con quel file.

 ????
 
$HOME/config
 
E` unico per ogni $HOME, non ci sono ambiguita`,
anche se il file ha lo stesso nome.
Quindi il path completo e` univoco.
 
bye,
 
-- 
 
piergiorgio

 script *localmente*.
 
Scusa Piergiorgio me lo dici al volo cosa fa - significa - serve
mettere "local" in una funzione d'uno script prima della variabile
(come ho visto in funzioni gia' fatte)?
 
Esempio:
pippo() {
local pluto="$1"
......
}
 
TIA ciao
 
-- 
Yoda
 


Immagino... Credo... Sospetto...
Che la variabile sia visibile solo
ed esclusivamente all'interno della
funzione.
 
Questo perche` magari tutte le
variabili sono altrimenti globali.
 
Comunque:
 
man local
 
Spiega vari shell builtin, incluso questo.
 
Tra l'altro ho notato, con orrore, che
python segue una filosofia simile: le
variabili dichiarate fuori delle funzioni
sono "globali", cioe` visibili all'interno
delle funzioni stesse...
Ed in modo assolutamente sorprendente, a volte.
 
bye,
 
-- 
 
piergiorgio

 script *localmente*.
 
OK, ma non hai spiegato cosa significa quella ***(d)***

 ad ogni shell che avvii viene inizializzata con quel file.
 
Questo file infatti, tra le varie cose, serve per esportare variabili 
in modo permanente.
Ed è proprio questo quello che mi interessava: esportare variabili 
permanenti evitando conflitti/sovrascritture, ecc. (chiedo scusa se non 
l'ho specificato bene dall'inizio).
 
Naturalmente i conflitti si possono avere anche dichiarando le variabili 
al volo: direttamente dal terminale.
 
$ export ABC=123
 
Poi però quando poi si esce (exit) tutto ritorna com'era.
In tal caso infatti i problemi/rischi dovrebbero essere un po' minori 
(riguardano solo una shell configurata al volo: senza memorizzare niente 
in nessun file di configurazione).
 
Ad ogni modo, ed in entrambi i casi di cui ho appena parlato, mi avete 
convinto che sono pratiche da evitare, e cercherò di farlo :D

 OK, ma non hai spiegato cosa significa quella ***(d)***
 
E` la forma verbale Inglese del comando.
 
Il comando e` "source", il file e` "sourced".
Dato che il comando e` "source", a volte si
usa scrivere "source(d)" relativamente
all'oggetto (che sarebbe il file, qui) in
modo da verbalizzare la frase, ma lasciare
evidenziato il comando stesso (source).
 
E` solo una forma espressiva breve.
 
bye,
 
-- 
 
piergiorgio

 E` solo una forma espressiva breve.
 
Come sopra, potresti cercare di spiegarla in modo più chiaro?
Dato che ci troviamo approfitto per imparare qualcosa in più :)

 Dato che ci troviamo approfitto per imparare qualcosa in più :)
 
Il comando sarebbe:
 
source conf.file
 
Quindi uno scrive che conf.file e` source(d).
 
In Inglese corretto sarebbe "conf.file is
sourced", sempre in Inglese, si modifica
in "conf.file is source(d)" in modo da
sottolineare il comando "source", e poi
si traduce :-) in Italiano il verbo "is".
 
bye,
 
-- 
 
piergiorgio

 man source
 
Scusa forse mi sa che scrivi "man" in automatica, ma volevo dirtelo
anche ieri per local, per i builtin ci vuole help, almeno qui da me
con la Debian ciao
 
-- 
Yoda
 


Da me, con Fedora, "man source" funziona.
 
bye,
 
-- 
 
piergiorgio

 E cosi` via...
 
Bene, ma potresti dirmi se è conveniente usare la stessa convenzione 
anche per gli user-script (quelli contenuti nella directory ~/bin)?
 
Ad es.
 
~/my-test
~/my-backup-documents