Newsgroup: it.comp.os.linux.iniziare
Titolo: script bash: problema con le date

Ho un problema che mi fa diventare matto.
Si tratta di uno script che viene eseguito giornalmente, tramite cron, e 
si occupa di fare il backup di una determinata directory.
Ogni venerdï¿œ, inoltre, dovrebbe fare il backup di una seconda directory.
Questo ï¿œ il testo:
-------------------
  # parte che viene eseguita giornalmente
  tar cvzfp /var/backup/documenti.tar.gz -C /media/hd2/dati documenti
  # parte che viene eseguita solo di venerdï¿œ
  datagiorno=$(date +%a)
  if [ $datagiorno = 'ven' ]
    then
  tar cvzfp /var/backup/roothtml.tar.gz -C /media/hd2/www html
-------------------
Se lancio lo script da terminale, funziona perfettamente.
Invece quando viene eseguito da cron, esegue solo la prima parte, mentre 
ignora completamente la seconda.
Dovrebbe fare il check sul giorno della settimana e proseguire in caso 
corrisponda a "ven" (uso Fedora 8 localizzata in italiano; ho provato a 
sostiture "ven" con "fri" ma non cambia nulla)
Come ho detto, eseguendo manualmente lo script questo funziona.
Dove sbaglio? :-/
m.
-- 
"La legge, in Italia, ï¿œ come l'onore delle puttane"
(Curzio Malaparte)

 Dove sbaglio? :-/
In inglese i giorni della settimana vanno scritti con la maiuscola; 
prova  'Fri'

 prova  'Fri'
Ma allora perchï¿œ lanciando lo script manualmente funziona, mentre da 
cron no?
E' questa la cosa che mi lascia perplesso.


 m.
Tipicamente quando uno script funziona correttamente a mano e non via
crontab c'� un problema di variabili d'ambiente. Personalmente quando
preparo script da usare a crontab cerco di dare per scontato il meno
possibile e di valorizzare, magari in testa allo script stesso, tutte le
variabili che mi possono essere utili.
Tipicamente � buona cosa:
- indicare i comandi con il path assoluto, perch� non � detto che il
contenuto della variabile $PATH sia lo stesso dentro e fuori dal crontab
- non assumere che la localizzazione venga gestita correttamente;
personalmente evito qualunque software tradotto come la peste perch� le
traduzioni, oltre ad essere spesso fatte cos� male da essere peggio che
inutili, introducono un ulteriore livello di complessit�
HTH,
Bud
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 variabili che mi possono essere utili.
  Direi che tu abbia proprio ragione.  Lo script deve avere una variabile
tra la LANG o le LC_*, come la LC_MESSAGES o la LC_ALL che è impostata ad
un valore diverso (o non è proprio impostata, e quindi assume il valore di
default C) dalla corrispondente variabile della shell utente.
  Le variabili d'ambiente della localizzazione linguistica e geografica
sono elencate e spiegate in locale(7).
  Concordo che la localizzazione debba essere usata solo quando
inevitabile, cioè solo per i messaggi diretti agli utenti finali, e mai
nella "roba da admin", e quindi negli script di sistema, di backup, di
gestione automatica delle policy di host o dominio ecc.
  Ciao,
-- 
Alessandro Selli 
http://alessandro.route-add.net
AVVERTENZA: i messaggi inviati a "trappola" non mi arriveranno.
WARNING: messages sent to "trappola" will never reach me.
Chiave PGP/GPG: EC885A8B

 ignora completamente la seconda.
Primo: cron esegue usando /bin/sh (o lo script indicato dal cron file, fai "man 
5 crontab" per piu` dettagli) che e` si linkato a /bin/bash ma che emula 
/bin/sh, con tutte le limitazioni che ti puoi immaginare... Il tuo processo 
interattivo invece gira bash.
Secondo: cron gira con un environment ristretto: molte variabili di environment 
potrebbero avere una definizione incompatibile con quella di un processo 
interattivo.
Per questo tipo di problemi, ti consiglio di fare "set -x" all'inizio del file e 
poi andare a leggere il mail che ti manda cron. Oppure fare il set e 
reindirizzare stdout e stderr su un file di log da analizzare post-mortem.
Ciao,
-- 
        Roberto Divia`              Love at first sight is one of the greatest
Dep:PH Bat:53 Mailbox:C02110      labour-saving devices the world has ever seen
Route de Meyrin 385               ---------------------------------------------
Case Postale                                Phone:  
+41-22-767-4994
CH-1211 Geneve 23 CERN                      Fax:    
+41-22-767-9585
Switzerland                                 E-Mail: 
Robert...@cern.ch

 
Ho capito ben poco della prima parte della risposta :-|
Purtroppo non ho una conoscenza metodica di bash e di linux in generale; 
cerco di documentarmi ed "arrangiarmi" di volta in volta a seconda delle 
necessitï¿œ.
grazie comunque


 necessitï¿œ.
Bash e` lo shell che tu usi in interattivo e che tu "programmi" con i tuoi shell 
script.
Non esiste un solo shell, ne esistono molti. Bash e` uno dei shell piu` 
sofisticati che io conosca. Ti offre molte estensioni che ovviamente non 
funzionano o funzionano diversamente in altri shell. Ovviamente uno script bash 
gira allo stesso modo su qualunque macchina su cui bash sia installato (almeno 
tra versioni compatibili di bash).
Ora, in una distribuzione Unix classica (non parlo di Linux, parlo di Unix) e` 
possibile avere piu` shell separati. Questo per poter girare script scritti per 
uno shell particolare, in modo tale da assicurarne la compatibilita`. Il piu` 
semplice di tutti questi shell e` "sh". Su qualunque sistema Unix tu ti trovi 
(Linux, Solaris, AIX, HP-UX...) , sei sicuro di trovare sh e sei praticamente 
sicuro della sua compatibilita`. Quindi, se vuoi scrivere uno shell che giri 
ovunque, devi scriverlo in sh.
Su Linux si era iniziato a mettere tutti gli shell, come su un Unix classico. 
Questo vuol dire che trovavi un /bin/sh, /bin/bash eccetera. Poi e` stata creata 
un estensione a bash dove basta fare un link simbolico a bash per farlo girare 
come se fosse un altro shell. Prova a fare:
cd /bin
ls -l | grep bash
e vedrai che esiste un /bin/sh che punta a /bin/bash. Questo vuol dire che se 
fai "sh" tu apri un nuovo bash che gira in modo compatibile sh e che quindi non 
capisce tutte le estensioni di bash.
cron usa (per default) sh. E` possibile forzare cron a usare altri shell, ma 
questo potrebbere rompere uno shell script che e` stato scritto per sh. Non 
dimenticare che tu non sei il solo a usare cron. Lo usa root e lo usano altri 
utilizzatori di sistema. Forzando cron a usare bash potresti rompere uno shell 
scritto e gestito da qualche pacchetto installato sulla macchina.
Se tu vuoi forzare uno script particolare a girare in bash indipendentemente 
dallo shell di origine, allora metti
#!/bin/bash
come prima linea dello script. Ovviamente questo non risolve il problema se lo 
script viene interpretato nello shell corrente (usando la sintassi ". script") 
ma questo non e` il tuo caso.
