Newsgroup: it.comp.os.linux.iniziare
Titolo: sovrascrittura variabili exportate

export abc=123
 
Ma se abc esiste già verrebbe sovrascritta
 
Soluzione complessa (non l'ho neanche testata):
 
[ [ ! -z "$abc" ] && echo 'Già esistente' ] || export abc=123
 
Soluzione semplice?
Possibile che export non abbia un'opzione per evitare sovrascritture 
accidentali?


Non ha alcun senso perché qualsiasi assegnazione sovrascrive il valore 
assegnato in precedenza.  E se fai una assegnazione è perché ti serve 
che la variabile assuma il nuovo valore.
 
Per rendere una variabile non sovrascrivibile la devi dichiarare r/o
 
$ lsodgf0@marina:~ > declare -r abc="stringa"
$ lsodgf0@marina:~ > echo $abc
stringa
$ lsodgf0@marina:~ > abc="xxxx"
bash: abc: readonly variable
$ lsodgf0@marina:~ > echo $abc
stringa
$ lsodgf0@marina:~ >
 
Ciao
Giovanni
-- 
   A computer is like an air conditioner,
   it stops working when you open Windows.
   < 
http://giovanni.homelinux.net/
 >

 che la variabile assuma il nuovo valore.
 
cp -i file1 file2
 
anche l'opzione -i a questo punto andrebbe abolita


Non sono sicuro quel test sia corretto.
 
Cosa succede se "abc" esiste, ma vale '', cioe`
stringa vuota?
 
bye,
 
-- 
 
piergiorgio

 stringa vuota?
 
E una stringa vuota non è una stringa come tutte le altre (cos'altro 
sarebbe?)?
O più in generale, una stringa non è un valore come tutti gli altri 
(cos'altro sarebbe?)?
 
Quindi il discorso è semplicemente sulla sovrascrittura di un valore 
(assegnato al nome di una variabile) di qualunque tipo esso sia (string, 
bool, integer, double...).

 bool, integer, double...).
 
Nessuno strumento di programmazione ti avverte se sovrascrivi il valore 
di una variabile a meno che questa non sia dichiarata read-only.
 
Al contrario!  Le variabili in genere sono modificate anche più di una 
volta in un programma.
 
$ lsodgf0@marina:~ > abc=""; [ -z "$abc" ] && echo "abc is empty" || 
echo "$abc"
abc is empty
$ lsodgf0@marina:~ > abc=" "; [ -z "$abc" ] && echo "abc is empty" || 
echo "$abc"
 
$ lsodgf0@marina:~ > unset abc; [ -z "$abc" ] && echo "abc is empty" || 
echo "$abc"
abc is empty
$ lsodgf0@marina:~ >
 
Come vedi una stringa vuota si comporta come se non esistesse quindi il 
test che proponi ti sovrascriverebbe il valore "" (cioè la stringa vuota.


 test che proponi ti sovrascriverebbe il valore "" (cioè la stringa vuota.
 
A questo punto per lavorare in sicurezza sarebbe opportuno usare un 
token (un suffisso pseudocasuale)
 
export PATH_gh4c49a=qualcosa
 


Ho chiesto del test che fai, non del resto.
 
Tu vuoi sapere se "abc" esiste (come nome di variabile,
che sarebbe meglio fosse maiuscolo).
 
Quel test potrebbe darti il risultato che "abc" non
esiste, se "abc" *esiste*, ma e` vuota.
 
Quindi chiedo: sei sicuro sia corretto testare con:
 
-z "$abc"
 
????
 
bye,
 
-- 
 
piergiorgio

 export PATH_gh4c49a=qualcosa
 
O sarebbe meglio riformulare il problema (non quello
della sovrascrittura) in maniera diversa.
 
Per quale motivo uno dovrebbe trovarsi nella situazione
di *rischiare* una sovrascrittura di variabile esportata?
 
Si e` mai sentita una cosa del genere? A parte qui...
 
Forse sarebbe da analizzare come si arriva a quel punto e,
magari, evitare di arrivarci.
 
bye,
 
-- 
 
piergiorgio

 ????
 
In effetti il mio approccio è sbagliato, hai ragione.

 magari, evitare di arrivarci.
 
export QUALCOSA_DI_DELICATO_DA_MODIFICARE_CON_COSCIENZA='e chi se ne frega'
 
Ma se voglio agire in modo responsabile (e considerando il fatto che 
export non mette a disposizione un'apposita security-option), prima di 
esportare una variabile devo fare i dovuti controlli (in modo manuale), 
per assicurarmi che non sia già esistente e, magari, usata da altri 
processi.

 processi.
 
Evita di fare queste cose, potrei sempre risponderti.
 
Come arrivi a tale situazione? Cosa stai tentando di
fare, che ti crea questi problemi?
 
Forse l'approccio iniziale e` sbagliato, forse si
puo` evitare di trovarsi in questa situazione.
 
Non saprei, hai un sistema di script cosi` complesso
da correre tali rischi?
 
bye,
 
-- 
 
piergiorgio

 da correre tali rischi?
 
$ cat .envrc
export PROJECT_BACKUP_DIR=/backups/project1
 
$ direnv allow
direnv: loading ~/.config/direnv/direnvrc
direnv: loading .envrc
direnv: export +EDITOR +PROJECT_BACKUP_DIR
 
$ cat backup.sh
#!/usr/bin/env bash
set -eu
cd "$(dirname "$0")"
rsync -av --delete . "$PROJECT_BACKUP_DIR"
chmod -R -w . # dopo il backup applichiamo un ulteriore protezione
# FINE DEI LAVORI: PER ADESSO IL PROGETTO È CHIUSO
 
$ ./backup.sh
sending incremental file list
...
 
Bene, ma se per caso PROJECT_BACKUP_DIR fosse usata anche da altri 
processi (ad esempio ../project2/backup.sh)?
Provo a lanciarlo, che dici?


Non ho capito niente di quale sia il problema,
ma direi che usare una variabile da .envrc ad
uno script sia gia` un errore.
 
Poi non so cosa sia "direnv".
 
bye,
 
-- 
 
piergiorgio

 Poi non so cosa sia "direnv".
 
google


le hanno inventate (le opzioni -i) per i principanti
Non ho mai visto nessuno usarle ed io stesso disabilito gli alias <cmd> -i
Sono solo una gran scocciatura
Ma comunque non puoi paragonare una opzione -i su un file (che potrebbe 
essere importante) con una variabile
Se proprio vuoi una variabile a sola lettura,come ti e' gia stato 
scritto,esiste readonly:
 
$ readonly xx=ggg
$ xx=mm
bash: xx: variabile in sola lettura
 
 
 
 

 Sono solo una gran scocciatura
 
Queste non le sapevo :DDD