Para "automatizar" o processo de importação do .sqlarquivo gerado , evitando todas as armadilhas que podem estar ocultas na tentativa de passar arquivos stdine stdout, basta dizer ao MySQL para executar o .sqlarquivo gerado usando o SOURCEcomando MySQL.
A sintaxe da resposta curta, mas excelente , de Kshitij Sood , fornece o melhor ponto de partida. Em resumo, modifique o comando do OP de acordo com a sintaxe de Kshitij Sood e substitua os comandos nele pelo SOURCEcomando:
#!/bin/bash
mysql -u$user -p$password $dbname -Bse "SOURCE ds_fbids.sql
SOURCE ds_fbidx.sql"
Se o nome do banco de dados estiver incluído no .sqlarquivo gerado , ele poderá ser removido do comando
A presunção aqui é que o arquivo gerado é válido como um .sqlarquivo por si só. Por não ter o arquivo redirecionado, canalizado ou de qualquer outra maneira manipulada pelo shell, não há problema em escapar de nenhum dos caracteres na saída gerada por causa do shell. As regras com relação ao que precisa ser escapado em um .sqlarquivo, é claro, ainda se aplicam.
Como lidar com os problemas de segurança em torno da senha na linha de comando ou em um my.cnfarquivo etc. foi bem abordado em outras respostas, com algumas sugestões excelentes. Minha resposta favorita , de Danny , cobre isso, incluindo como lidar com o problema ao lidar com crontrabalhos ou qualquer outra coisa.
Para endereçar um comentário (pergunta?) Sobre a resposta curta que mencionei: Não, ele não pode ser usado com uma sintaxe HEREDOC, pois esse comando é fornecido. O HEREDOC pode ser usado na sintaxe da versão de redirecionamento (sem a -Bseopção), pois o redirecionamento de E / S é o que o HEREDOC constrói. Se você precisar da funcionalidade do HEREDOC, seria melhor usá-lo na criação de um .sqlarquivo, mesmo que seja temporário, e use esse arquivo como o "comando" para executar com a linha de lote do 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
Lembre-se de que, devido à expansão do shell, você pode usar variáveis de ambiente e shell no HEREDOC. A desvantagem é que você deve escapar de cada backtick. O MySQL os usa como delimitadores para identificadores, mas o shell, que obtém a string primeiro, os usa como delimitadores de comando executável. Perca a fuga com um único backtick dos comandos do MySQL, e a coisa toda explode com erros. O problema todo pode ser resolvido usando um LimitString entre aspas para o 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
Remover a expansão do shell dessa maneira elimina a necessidade de escapar dos backticks e outros caracteres especiais do shell. Ele também remove a capacidade de usar variáveis de ambiente e shell dentro dele. Isso praticamente remove os benefícios de usar um HEREDOC dentro do script de shell, para começar.
A outra opção é usar as seqüências de citação de várias linhas permitidas no Bash com a versão da sintaxe em lote (com o -Bse). Eu não conheço outras conchas, então não posso dizer se elas funcionam nela também. Você precisaria usar isso para executar mais de um .sqlarquivo com o SOURCEcomando de qualquer maneira, já que isso não é finalizado por um ;como outros comandos do MySQL, e apenas um é permitido por linha. A cadeia de linhas múltiplas pode ser simples ou dupla, com os efeitos normais na expansão do shell. Ele também possui as mesmas ressalvas que o uso da sintaxe HEREDOC para backticks, etc.
Uma solução potencialmente melhor seria usar uma linguagem de script, Perl, Python, etc., para criar o .sqlarquivo, como o OP, e SOURCEesse arquivo usando a sintaxe de comando simples na parte superior. As linguagens de script são muito melhores na manipulação de strings do que o shell, e a maioria possui procedimentos embutidos para lidar com as aspas e escapamentos necessários ao lidar com o MySQL.