Newsgroup: it.comp.os.linux.iniziare
Titolo: problema (stupido) con mysqldump

Utilizzo MYSQLDUMP per eseguire il backup di un database.
La sintassi è questa:
# mysqldump database > /percorso/backup.sql -u root
da riga di comando funziona, ma se inserisco il comando in uno script 
no... difatti ottengo:
couldn't find table: ">"
Evidentemente il carattere ">" viene interpretato come il nome del 
database piuttosto che effettuare il redirezionamento dell'output.
Come faccio a farglielo capire?
m.
-- 
"La legge, in Italia, è come l'onore delle puttane"
(Curzio Malaparte)

 # mysqldump database > /percorso/backup.sql -u root
Mi rispondo da solo.
Ho provato ad utilizzare l'opzione "-r"
# mysqldump database -r /percorso/backup.sql -u root
Così sembra funzionare.
Da quanto ho capito, tale opzione serve a forzare la scrittura diretta 
su un file; poiché ">" indica come direzionare l'output (video, file 
ecc.) nonostante la differenza concettuale tra i due comandi il 
risultato è lo stesso, giusto?
Se è così, perché la documentazione ufficiale invita ad utilizzare la 
seconda soluzione, quando la prima dovrebbe essere più corretta?
O sono tutte pippe mentali mie? :-)
(cmq, ho reimportato il file così creato e mi sembra sia tutto a posto)
ciao


 Come faccio a farglielo capire?
La redirezione va in FONDO alle opzioni, non in mezzo. Sennò stai facendo
qualcosa strano con lo script, perchè io ho decine di cron così e
funzionano perfettamente.
-- 
Vide

Vide ha scritto:

No, avevo provato anche in questo modo ottenendo lo stesso errore.
Inoltre avevo provato anche una cosa di questo genere:
# mysqldump database -u root | bzip2 -c > /backup/database.sql.bz2
ed ottenevo allora: couldn't find table "|"
Insomma, sembrava proprio che non riuscisse a gestire l'output.
Se non altro, come dicevo, ho risolto con l'opzione "-r".
Comunque da una ricerca con Google ho visto che non sono l'unico ad aver 
lamentato il problema.
mah...


 # mysqldump database -u root | bzip2 -c > /backup/database.sql.bz2
#!/bin/bash
mysqldump -u root -pXXXXXX -d db_prova > /tmp/prova.sql
funziona perfettamente, con 
mysqldump  Ver 10.9 Distrib 4.1.14, for pc-linux-gnu (i68
cioè, più che vecchio.
-- 
Vide

 risultato è lo stesso, giusto?
Da man mysqldump
--result-file=file, -r file
Direct output to a given file. This option should be used on Windows to
prevent newline `\n' characters from being converted to `\r\n'
carriagereturn/newline sequences. The result file is created and its
contents overwritten, even if an error occurs while generating the dump.
The previous contents are lost.
ovvero è una opzione per gli utenti Windows visto che gli Unix hanno un >
che funziona perfettamente :P
-- 
Vide

 funziona perfettamente, con
Domanda: non è che stai mettendo qualche virgoletta/apice di troppo nello
script?
-- 
Vide

 script?
anfatti
ps: negli script di cron č sempre bene mettere i percorsi completi anche
degli eserguibili (/usr/bin/mysqldump o quel che č)

 
In effetti ciavete ragione, e la colpa è nella mia ignoranza della 
programmazione bash.
Uno script di questo tipo funziona:
mysqldump database -u root > /percorso/backup.sql
Quest'altro no ("couldn't find table '>' "):
comando="mysqldump database -u root > /percorso/backup.sql"
$comando
La differenza è che nel secondo caso il comando è contenuto in una 
variabile (per ordine mentale mio :-P )
Certo posso eseguire il comando direttamente senza "incorporarlo" in una 
variabile, però non capisco perché, ad esempio, un semplice TAR funzioni 
anche in questo modo e un MYSQLDUMP no. :-/
grazie per la dritta :-)


 grazie per la dritta :-)
Figurati :)
-- 
Vide