Per "automatizzare" il processo di importazione del .sqlfile generato , evitando tutte le trappole che possono essere nascoste nel tentativo di passare i file stdine stdout, basta dire a MySQL di eseguire il .sqlfile generato usando il SOURCEcomando in MySQL.
La sintassi nella risposta breve, ma eccellente , di Kshitij Sood , fornisce il miglior punto di partenza. In breve, modifica il comando dell'OP in base alla sintassi di Kshitij Sood e sostituisci i comandi in quello con il SOURCEcomando:
#!/bin/bash
mysql -u$user -p$password $dbname -Bse "SOURCE ds_fbids.sql
SOURCE ds_fbidx.sql"
Se il nome del database è incluso nel .sqlfile generato , può essere eliminato dal comando.
La presunzione qui è che il file generato sia valido come .sqlfile da solo. Non avendo il file reindirizzato, reindirizzato o gestito in altro modo dalla shell, non vi è alcun problema con la necessità di sfuggire a nessuno dei caratteri nell'output generato a causa della shell. Le regole relative a ciò che deve essere evaso in un .sqlfile, ovviamente, si applicano comunque.
Come affrontare i problemi di sicurezza relativi alla password nella riga di comando, o in un my.cnffile, ecc., È stato ben affrontato in altre risposte, con alcuni suggerimenti eccellenti. La mia risposta preferita , da Danny , copre questo, incluso come gestire il problema quando si tratta di cronlavori o altro.
Per rispondere a un commento (domanda?) Sulla risposta breve che ho citato: No, non può essere usato con una sintassi HEREDOC, dato che viene dato quel comando shell. HEREDOC può essere utilizzato nella sintassi della versione di reindirizzamento , (senza l' -Bseopzione), poiché il reindirizzamento I / O è ciò su cui è costruito HEREDOC. Se hai bisogno della funzionalità di HEREDOC, sarebbe meglio usarlo nella creazione di un .sqlfile, anche se è temporaneo, e usare quel file come "comando" per eseguire con la linea batch di MySQL.
#!/bin/bash
cat >temp.sql <<SQL_STATEMENTS
...
SELECT \`column_name\` FROM \`table_name\` WHERE \`column_name\`='$shell_variable';
...
SQL_STATEMENTS
mysql -u $user -p$password $db_name -Be "SOURCE temp.sql"
rm -f temp.sql
Tenere presente che a causa dell'espansione della shell è possibile utilizzare variabili shell e ambiente all'interno di HEREDOC. Il rovescio della medaglia è che devi sfuggire a ogni backtick. MySQL li usa come delimitatori per gli identificatori ma la shell, che ottiene per prima la stringa, li usa come delimitatori di comandi eseguibili. Perdere la fuga su un singolo backtick dei comandi MySQL e il tutto esplode con errori. L'intero problema può essere risolto utilizzando un LimitString citato per HEREDOC:
#!/bin/bash
cat >temp.sql <<'SQL_STATEMENTS'
...
SELECT `column_name` FROM `table_name` WHERE `column_name`='constant_value';
...
SQL_STATEMENTS
mysql -u $user -p$password $db_name -Be "SOURCE temp.sql"
rm -f temp.sql
Rimuovere l'espansione della shell in questo modo elimina la necessità di sfuggire ai backtick e ad altri caratteri speciali della shell. Rimuove inoltre la possibilità di utilizzare al suo interno variabili di shell e ambiente. Questo praticamente toglie i vantaggi dell'utilizzo di un HEREDOC all'interno dello script della shell per cominciare.
L'altra opzione è utilizzare le stringhe tra virgolette multilinea consentite in Bash con la versione della sintassi batch (con il -Bse). Non conosco altri gusci, quindi non posso dire se funzionano anche lì. Dovresti usarlo per eseguire più di un .sqlfile con il SOURCEcomando comunque, poiché questo non è terminato da un ;come lo sono altri comandi MySQL e ne è consentito solo uno per riga. La stringa a più righe può essere virgoletta singola o doppia, con i normali effetti sull'espansione della shell. Ha anche le stesse avvertenze dell'uso della sintassi HEREDOC per i backtick, ecc.
Una soluzione potenzialmente migliore sarebbe quella di utilizzare un linguaggio di scripting, Perl, Python, ecc., Per creare il .sqlfile, come ha fatto l'OP, e SOURCEquel file usando la semplice sintassi dei comandi in alto. I linguaggi di scripting sono molto più efficaci nella manipolazione delle stringhe rispetto alla shell, e la maggior parte ha procedure integrate per gestire le quotazioni e gli escape necessari quando si ha a che fare con MySQL.