|
| Precedente :: Successivo |
| Autore |
Messaggio |
anabasi
Amministratore
Registrato: 21/10/05 00:58
Messaggi: 14543
Residenza: Tra Alpi e Tanaro
|
 Inviato: 05 Set 2008 18:43 Oggetto: * Un semplice script per rsync |
 |
|
Anche in questo caso ho avuto qualche incertezza nello scegliere il forum in cui inserire il post: l'argomento ha qualche parentela con la programmazione, ma essendo riferito a una distribuzione Linux credo che nel forum "Linux" possa trovare più risposte.
Utilizzo rsync per effettuare copie di backup di alcune cartelle contenenti dati: le cartelle "sorgente" risiedono sull'hard disk e le cartelle "destinazione" su un hard disk esterno. Per essere precisi, non si tratta di un vero backup, ma della sincronizzazione tra le due cartelle; inoltre, finora non ho utilizzato rsync da linea di comando, bensì tramite Grsync, l'interfaccia grafica offerta da Gnome.
Grsync permette di salvare differenti profili (che chiama "sessioni"), a ciascuno dei quali corrisponde una cartella. Essendo relativamente numerose le cartelle da controllare, e poiché Grsync non permette di unificare le singole sessioni in un'unica, finora sono stato costretto ad avviare una sessione, aspettare che rsync terminasse il confronto e l'aggiornamento, avviare la sessione successiva, e così via fino all'ultima.
Dai log di Grsync ho ricavato i comandi (opzioni comprese) per ciascuna sessione, con l'intenzione di scrivere uno script che lanciasse una sessione dopo l'altra, senza il mio intervento. Ho fatto qualche esperimento, con delle cartelle contenenti dati inutili, e mi sembra che tutto funzioni.
Prima di eseguire lo script, con le opportune modifiche di path, sulle "vere" cartelle di backup (e di combinare un disastro  ) vorrei però risolvere qualche dubbio...
Questo è lo script di simulazione, che funziona correttamente:
| Codice: |
echo "SESSIONE DOCUMENTI 1"
rsync -r -t -v --progress --delete --modify-window=1 -c /mnt/sda5/documenti_1/ /media/disk/backup/documenti_1/
echo "SESSIONE DOCUMENTI 2"
rsync -r -t -v --progress --delete --modify-window=1 -c /mnt/sda5/documenti_2/ /media/disk/backup/documenti_2/
echo "SESSIONE DOCUMENTI 3"
rsync -r -t -v --progress --delete --modify-window=1 -c /mnt/sda5/documenti_3/ /media/disk/backup/documenti_3/
|
Non ho dubbi per quanto riguarda la correttezza dei comandi rsync, avendoli ricavati dai log di Grsync.
Con il comando echo ottengo nel terminale il nome di ciascuna sessione, in modo da separarle l'una dall'altra e poter più facilmente verificare da terminale il lavoro eseguito.
Veniamo alle domande:
- E' "formalmente" corretto il modo di scrivere lo script?
- Le righe vuote sono ben accettate, oppure sarebbe meglio eliminarle?
- Occorre indicare, all'inizio, quale shell deve eseguire lo script? Lo chiedo perché ho trovato alcuni esempi di script che iniziavano con #!/bin/sh, ma immagino che volendo utilizzare bash (shell di default per Ubuntu) non occorra indicare niente.
- Per rendere eseguibile il file ho usato il comando chmod +x nomefile
- Il file deve avere una determinata estensione (ad es: .sh)? Ho provato ad eseguire da terminale un file senza estensione, e ha funzionato ugualmente. (L'unica differenza che ho notato è che, componendo con Gedit lo script in un file con l'estensione .sh , Gedit aiuta la scrittura con colorazioni differenti)
- In quale cartella è consigliabile salvare gli script? (Ovviamente funzionano da qualunque cartella, ma per la vostra esperienza dove è preferibile salvarli?)
- Qual è l'alternativa a lanciare lo script da terminale? Io ho provato a creare un lanciatore sul desktop, impostandolo come "applicazione nel terminale" e indicando come comando il percorso del file. Funziona, si apre il terminale e viene eseguito lo script, ma al termine dell'esecuzione il terminale viene chiuso e non è possibile controllare il lavoro effettuato; c'è modo di lasciare il terminale aperto?
Scusate le molte domande; so che alcune sono ovvie, ma non per chi è all'inizio...
Grazie 
PS: Qualcuno è in grado di indicare il link ad un manuale o anche soltanto a qualche pagina introduttiva allo scripting per Bash, preferibilmente in italiano? |
|
| Top |
|
 |
MK66
Moderatore Sistemi Operativi
Registrato: 17/10/06 22:24
Messaggi: 8616
Residenza: dentro una cassa sotto 3 metri di terra...
|
| Inviato: 05 Set 2008 23:26 Oggetto: Re: Un semplice script per rsync |
|
|
| anabasi ha scritto: | | Anche in questo caso ho avuto qualche incertezza nello scegliere il forum in cui inserire il post: l'argomento ha qualche parentela con la programmazione, ma essendo riferito a una distribuzione Linux credo che nel forum "Linux" possa trovare più risposte. |
Proviamo a vedere se ti risponde qualcuno che ne capisce davvero, altrimenti lo sposto in programmazione.
| anabasi ha scritto: |
Veniamo alle domande:
- E' "formalmente" corretto il modo di scrivere lo script?
- Le righe vuote sono ben accettate, oppure sarebbe meglio eliminarle?
- Occorre indicare, all'inizio, quale shell deve eseguire lo script? Lo chiedo perché ho trovato alcuni esempi di script che iniziavano con #!/bin/sh, ma immagino che volendo utilizzare bash (shell di default per Ubuntu) non occorra indicare niente.
- Per rendere eseguibile il file ho usato il comando chmod +x nomefile
- Il file deve avere una determinata estensione (ad es: .sh)? Ho provato ad eseguire da terminale un file senza estensione, e ha funzionato ugualmente. (L'unica differenza che ho notato è che, componendo con Gedit lo script in un file con l'estensione .sh , Gedit aiuta la scrittura con colorazioni differenti)
- In quale cartella è consigliabile salvare gli script? (Ovviamente funzionano da qualunque cartella, ma per la vostra esperienza dove è preferibile salvarli?)
- Qual è l'alternativa a lanciare lo script da terminale? Io ho provato a creare un lanciatore sul desktop, impostandolo come "applicazione nel terminale" e indicando come comando il percorso del file. Funziona, si apre il terminale e viene eseguito lo script, ma al termine dell'esecuzione il terminale viene chiuso e non è possibile controllare il lavoro effettuato; c'è modo di lasciare il terminale aperto?
Scusate le molte domande; so che alcune sono ovvie, ma non per chi è all'inizio...
Grazie
PS: Qualcuno è in grado di indicare il link ad un manuale o anche soltanto a qualche pagina introduttiva allo scripting per Bash, preferibilmente in italiano? |
Scusami, ma le mie incompetenze in merito non mi permettono di rispondere a tutte le domande
Per quel poco che mi serve a me, seguo le indicazioni di base di queste guide:
il wiki di ubuntu (ovviamente)
una buona guida per i principianti come me (il pdf scaricabile è in italiano...)
Per il resto, le risposte che posso darti io sono queste:
- lo script deve sempre cominciare con il richiamo della shell (se usi bash dovrai iniziare con #!/bin/bash, se usi altre shell dovrai cominciare con la giusta shell), e va indicata comunque, anche se è la shell di default
- le righe vuote non dovrebbero dare problemi (anche se, a dire la verità, in quel poco che ho fatto io non mi ricordo di averle messe...)
- io mi sono creato nella home una cartella script dove li salvo, per averli a portata di mano. Li salvo normalmente con estensione .sh e li rendo eseguibili con il comando che hai indicato (chmod +x nomefile.sh), anche se non è realmente necessaria l'estensione, è un pò una mia mania per riconoscerli al volo... e per sfruttare la comodità del gedit che hai già notato... |
|
| Top |
|
|
anabasi
Amministratore
Registrato: 21/10/05 00:58
Messaggi: 14543
Residenza: Tra Alpi e Tanaro
|
| Inviato: 07 Set 2008 06:34 Oggetto: |
|
|
| MK66 ha scritto: | | [...] le mie incompetenze in merito non mi permettono di rispondere a tutte le domande |
Sei stato più che esauriente, grazie.
Ho dato soltanto una veloce occhiata al how-to che mi hai indicato, ma credo che sia proprio ciò che stavo cercando: una guida introduttiva, adatta alle mie limitate esigenze.
In precedenza, avevo trovato un manuale completo sullo scripting in bash. Scritto in inglese (e passi...), e ben 500 pagine escluse le appendici (e questo era troppo... ) In seguito, ho scoperto che il Wiki di Ubuntu lo considera addirittura la "bibbia del bash scripting"...
| MK66 ha scritto: | | lo script deve sempre cominciare con il richiamo della shell (se usi bash dovrai iniziare con #!/bin/bash, se usi altre shell dovrai cominciare con la giusta shell), e va indicata comunque, anche se è la shell di default |
OK, la indicherò sempre.
Tu usi bash, immagino; ho letto che offre molte più funzionalità di sh e che è adatta a tutti, esperti e meno.
Una cosa mi ha incuriosito: se le righe "commentate" con # non vengono prese in considerazione, perché il richiamo della shell #!/bin/bash inizia con un #?
Mentre parliamo di righe commentate, ne approfitto...
Sai perché in alcuni file di sistema di Linux (per es, menu.lst) vi sono righe che iniziano con un doppio commento ##?
Se, come immagino, il doppio commento equivale a nessun commento...
Il comando per lanciare da terminale uno script è sempre ./nomescript.sh oppure vi possono essere altri casi?
Grazie per la pazienza! |
|
| Top |
|
|
MK66
Moderatore Sistemi Operativi
Registrato: 17/10/06 22:24
Messaggi: 8616
Residenza: dentro una cassa sotto 3 metri di terra...
|
| Inviato: 07 Set 2008 21:15 Oggetto: |
|
|
Quella che hai trovato è la versione "avanzata", quella che ti ho linkato io è la versione base... ce l'ho entrambe e le sto studiando, ma... per il momento riesco solo a capire qualcosa della base... 
Premesso che sono il meno indicato da questa parte dell'universo conosciuto a rispondere a domande di programmazione, cercherò comunque di... dirti quello che ho capito... non ci vorrà molto... 
Uso la bash perchè tutta la documentazione che ho trovato fa riferimento a quella, e i comandi principali da terminale che conosco (quelli che, messi poi insieme, si trasformano nei "miei" script...) sono scritti con la sintassi della bash (così è più semplice capire dove ho fatto errori...), ma ovviamente ce ne sono tantissime di shell, dalla base ( sh ) alle varianti diverse...
La combinazione #! dovrebbe essere il comando di esecuzione della shell (e non un commento), seguito dal percorso della shell stessa /bin/bash... in alcuni punti ho visto la scritta separata ( #! /bin/bash ) ma dovrebbe essere egualmente funzionante (mai provato...)
Non saprei, io so (parolone... diciamo che io ho sentito) che i caratteri che vengono dopo un commento non sono letti dal compilatore, indipendentemente dal fatto che sia un altro #... quindi il doppio # sarebbe solo una ridondanza...  (ma non ti consiglio di provare a levarlo prima di aver letto fino in fondo la guida... e nemmeno dopo... )
Per il comando, non so se c'è altro: io ho sempre usato quello ( ./nomescript.sh ), direttamente da terminale se era uno script "usa e getta"... o associato a un lanciatore se era qualcosa di uso continuativo.
Spero di non averti confuso ulteriormente le idee...
 |
|
| Top |
|
|
anabasi
Amministratore
Registrato: 21/10/05 00:58
Messaggi: 14543
Residenza: Tra Alpi e Tanaro
|
| Inviato: 08 Set 2008 18:50 Oggetto: |
|
|
| MK66 ha scritto: | | Quella che hai trovato è la versione "avanzata", quella che ti ho linkato io è la versione base... ce l'ho entrambe e le sto studiando, ma... per il momento riesco solo a capire qualcosa della base... |
A chi lo dici...
| MK66 ha scritto: | | Uso la bash perchè tutta la documentazione che ho trovato fa riferimento a quella, e i comandi principali da terminale che conosco (quelli che, messi poi insieme, si trasformano nei "miei" script...) sono scritti con la sintassi della bash (così è più semplice capire dove ho fatto errori...), ma ovviamente ce ne sono tantissime di shell, dalla base ( sh ) alle varianti diverse... |
Ho trovato una breve Guida_allo_Shell_Scripting (una dozzina di pagine web) basata su sh.
Ho letto che bash è compatibile con sh: i comandi che funzionano con sh, funzionano anche con bash, ma non è sempre vero il contrario.
| MK66 ha scritto: | La combinazione #! dovrebbe essere il comando di esecuzione della shell (e non un commento), seguito dal percorso della shell stessa /bin/bash [...]
...
[...] i caratteri che vengono dopo un commento non sono letti dal compilatore, indipendentemente dal fatto che sia un altro #... quindi il doppio # sarebbe solo una ridondanza... |
OK, ma allora...come può il compilatore interpretare correttamente il comando di esecuzione della shell (la combinazione #!) ? Dovrebbe arrivare al #, considerarlo un commento e non leggere oltre...
| MK66 ha scritto: | | (ma non ti consiglio di provare a levarlo prima di aver letto fino in fondo la guida... e nemmeno dopo... ) |
Seguirò il tuo saggio consiglio!
| MK66 ha scritto: | | io ho sempre usato quello ( ./nomescript.sh ), direttamente da terminale se era uno script "usa e getta"... o associato a un lanciatore se era qualcosa di uso continuativo |
Nel caso di utilizzo del lanciatore, immagino che tu lo imposti come "applicazione nel terminale". Ti risulta che sia possibile impedire al terminale di chiudersi automaticamente, appena finita l'esecuzione dello script?
| MK66 ha scritto: | | Spero di non averti confuso ulteriormente le idee... |
No, tutt'altro. Hai risolto molti miei dubbi, e confermato altre cose che avevo solo intuito!
Adesso, bisognerebbe trovare il tempo e mettersi a studiare!
Ancora...grazie per la pazienza! |
|
| Top |
|
|
MK66
Moderatore Sistemi Operativi
Registrato: 17/10/06 22:24
Messaggi: 8616
Residenza: dentro una cassa sotto 3 metri di terra...
|
| Inviato: 08 Set 2008 22:29 Oggetto: |
|
|
Gli script sono processati dalla shell secondo la propria sintassi
E' vero che il # indica un commento, ma ho visto che la combinazione #! è l'identificativo per indicare che quello che segue è uno script (poi gli si dice quale shell dovrà processare lo script, indicando il percorso: /bin/bash o /bin/sh o /bin/csh... o quella che vuoi... )
Secondo il parere di uno "gnurant", probabilmente quando l'interprete vede il # controlla il carattere subito dopo e, se non è un ! allora lo interpreta come un commento... ma come ho detto, questo è il parere di uno "gnurant"
Non ho mai provato a impedire la chiusura del terminale (i miei sono scriptini di pulizia o di copiatura di dati da una partizione all'altra...), mi viene in mente di inserire al termine del codice un & ( ) ma non ho ancora studiato quella parte... |
|
| Top |
|
|
anabasi
Amministratore
Registrato: 21/10/05 00:58
Messaggi: 14543
Residenza: Tra Alpi e Tanaro
|
| Inviato: 10 Set 2008 19:02 Oggetto: |
|
|
Ho finalmente collaudato il mio primo "scriptino": tutto ha funzionato, senza imprevisti e senza cancellare accidentalmente qualche cartella importante! 
Per la prima volta, da quando uso Ubuntu, ho potuto effettuare il backup dei miei dati avviandolo e...occupandomi di altro, per ritornare a cose fatte! 
In precedenza, come avevo accennato, tramite l'interfaccia di Grsync dovevo lanciare l'aggiornamento di una singola cartella, aspettare che finisse e passare alla seconda, e così via. 
Grazie per l'assistenza! |
|
| Top |
|
|
MK66
Moderatore Sistemi Operativi
Registrato: 17/10/06 22:24
Messaggi: 8616
Residenza: dentro una cassa sotto 3 metri di terra...
|
| Inviato: 10 Set 2008 22:58 Oggetto: |
|
|
Per quello che riguarda il terminale che resti aperto, ho preso informazioni e ci sono più alternative:
1) lanci lo script direttamente da terminale e non da lanciatore, quindi al termine del comando il terminale resta aperto, in attesa di una nuova istruzione
2) imposti nel profilo del terminale che "non si chiuda al termine del comando" (dal menù modifica del terminale vai nella scheda del tuo profilo e lo modifichi, si apre una finestra con più schede... nella seconda "Titolo e comando" l'ultima casella indica cosa deve fare il terminale al termine del comando, è impostata per "uscire dal terminale", ma puoi scegliere di "lasciare aperto il terminale"
3) imposti lo script che, al termine di ciò che deve fare, resti comunque in attesa di una istruzione di input da parte tua... ma questo è un metodo veramente osceno... |
|
| Top |
|
|
anabasi
Amministratore
Registrato: 21/10/05 00:58
Messaggi: 14543
Residenza: Tra Alpi e Tanaro
|
| Inviato: 18 Set 2008 18:51 Oggetto: |
|
|
| MK66 ha scritto: | | Non ho mai provato a impedire la chiusura del terminale (i miei sono scriptini di pulizia o di copiatura di dati da una partizione all'altra...) |
Interessante...potresti dirci qualcosa di più a proposito degli script di pulizia? Finora non mi ero mai posto il problema...
| MK66 ha scritto: | | 1) lanci lo script direttamente da terminale e non da lanciatore, quindi al termine del comando il terminale resta aperto, in attesa di una nuova istruzione |
E' la soluzione che ho scelto. Quando voglio fare un backup senza preoccuparmi di controllarne l'esecuzione, lancio lo script con il lanciatore; quando voglio verificare con calma il log del backup, lancio lo script da terminale.
| MK66 ha scritto: | | 2) imposti nel profilo del terminale che "non si chiuda al termine del comando" (dal menù modifica del terminale vai nella scheda del tuo profilo e lo modifichi, si apre una finestra con più schede... nella seconda "Titolo e comando" l'ultima casella indica cosa deve fare il terminale al termine del comando, è impostata per "uscire dal terminale", ma puoi scegliere di "lasciare aperto il terminale" |
Ho controllato, e anche nel mio caso il profilo è così impostato: "Quando il comando termina: uscire dal terminale". Non ho provato a modificare l'impostazione, anche perchè tutto sommato preferisco che sia così, altrimenti ogni volta che con il lanciatore avvio la connessione adsl il terminale rimarrebbe aperto per l'intera connessione.
Un dubbio: il profilo impostato in modalità "Quando il comando termina: uscire dal terminale" non dovrebbe chiudere il terminale sempre (cioè anche quando apro il terminale, digito un comando e questo viene eseguito)?
In questo caso, invece, rimane (giustamente) aperto... |
|
| Top |
|
|
MK66
Moderatore Sistemi Operativi
Registrato: 17/10/06 22:24
Messaggi: 8616
Residenza: dentro una cassa sotto 3 metri di terra...
|
| Inviato: 18 Set 2008 21:48 Oggetto: |
|
|
| anabasi ha scritto: | | MK66 ha scritto: | | Non ho mai provato a impedire la chiusura del terminale (i miei sono scriptini di pulizia o di copiatura di dati da una partizione all'altra...) |
Interessante...potresti dirci qualcosa di più a proposito degli script di pulizia? Finora non mi ero mai posto il problema... |
Beh, la pulizia del sistema segue le indicazioni di questa guida e del link correlato sulla pulizia della cache di apt eccetera.
Io non ho fatto altro che trasformare quella serie di comandi in un paio di script che lancio e... fanno tutto da soli 
| anabasi ha scritto: | Un dubbio: il profilo impostato in modalità "Quando il comando termina: uscire dal terminale" non dovrebbe chiudere il terminale sempre (cioè anche quando apro il terminale, digito un comando e questo viene eseguito)?
In questo caso, invece, rimane (giustamente) aperto... |
Credo che per "comando" si intenda l'esecuzione di uno script (in particolare come applicazione da terminale), altrimenti non avrebbe senso nemmeno usare il terminale: dai un qualsiasi comando, per esempio un banale ls -la e, al termine del comando (prima ancora che tu possa leggere il risultato) il terminale si chiuderebbe... 
(per dovere di cronaca, il banale comando di cui ho parlato non fa altro che elencare tutto il contenuto della directory corrente, compresi i file nascosti, in formato tale da vedere sia i permessi che il proprietario del suddetto file, cartella, link) |
|
| Top |
|
|
anabasi
Amministratore
Registrato: 21/10/05 00:58
Messaggi: 14543
Residenza: Tra Alpi e Tanaro
|
| Inviato: 19 Set 2008 19:25 Oggetto: |
|
|
| MK66 ha scritto: | | Credo che per "comando" si intenda l'esecuzione di uno script (in particolare come applicazione da terminale), altrimenti non avrebbe senso nemmeno usare il terminale: dai un qualsiasi comando, per esempio un banale ls -la e, al termine del comando (prima ancora che tu possa leggere il risultato) il terminale si chiuderebbe... |
E' vero...
probabilmente, nella traduzione delle voci dell'interfaccia grafica dall'inglese (molto più conciso) all'italiano qualcosa si è perso, dovendo il traduttore "far stare tutto" in poco spazio.
Vorrei chiedere ancora qualcosa sulla pulizia del sistema: per non andare OT in questo thread, mi sposto qui. |
|
| Top |
|
|
anabasi
Amministratore
Registrato: 21/10/05 00:58
Messaggi: 14543
Residenza: Tra Alpi e Tanaro
|
| Inviato: 21 Set 2008 10:57 Oggetto: |
 |
|
Nel primo post non ho scritto che cosa fa rsync quando gli si dà il comando:
| Codice: |
rsync -r -t -v --progress --delete --modify-window=1 -c
|
Nel caso qualcuno volesse utilizzarlo, sappia che il comando adegua la cartella "destinazione" alla cartella "sorgente":
- Inserisce nella cartella "destinazione" file e cartelle mancanti, e presenti nella cartella "sorgente"
- Modifica nella cartella "destinazione" file modificati nella cartella "sorgente"
- Elimina dalla cartella "destinazione" file e cartelle non presenti nella cartella "sorgente"
In particolare, è importante l'ultimo punto. A me interessa avere due cartelle perfettamente uguali, ma ciò comporta che nel caso di una cancellazione non voluta di un file nella cartella "sorgente", dopo l'azione di rsync non sarà possibile recuperare il file nemmeno nella cartella "destinazione". Ugualmente, il salvataggio di un file nuovo nella cartella "destinazione" causerebbe la sua immediata eliminazione.
| Codice: |
echo "SESSIONE DOCUMENTI 1"
rsync -r -t -v --progress --delete --modify-window=1 -c /mnt/sda5/documenti_1/ /media/disk/backup/documenti_1/
echo "SESSIONE DOCUMENTI 2"
rsync -r -t -v --progress --delete --modify-window=1 -c /mnt/sda5/documenti_2/ /media/disk/backup/documenti_2/
echo "SESSIONE DOCUMENTI 3"
rsync -r -t -v --progress --delete --modify-window=1 -c /mnt/sda5/documenti_3/ /media/disk/backup/documenti_3/
|
|
|
| Top |
|
|
|
|
Non puoi inserire nuovi argomenti
Non puoi rispondere a nessun argomento
Non puoi modificare i tuoi messaggi
Non puoi cancellare i tuoi messaggi
Non puoi votare nei sondaggi
|
|
FAQ
Cerca
Lista utenti
Gruppi
Registrati
Profilo
Messaggi privati
Log in
