Чтобы "автоматизировать" процесс импорта сгенерированного файла .sql, избегая при этом всех ловушек, которые могут быть скрыты при попытке пропустить файлы через stdin и stdout, просто скажите MySQL выполнить сгенерированный .sql файл с помощью команды SOURCE в MySQL.
Синтаксис в коротком, но превосходном, ответе от Кшитый Суд , дает лучшую отправную точку. Короче говоря, измените команду OP согласно синтаксису Kshitij Sood и замените команды в ней командой SOURCE:
#!/bin/bash
mysql -u$user -p$password $dbname -Bse "SOURCE ds_fbids.sql
SOURCE ds_fbidx.sql"
Если имя базы данных включено в сгенерированный файл .sql, его можно удалить из команды.
Предполагается, что сгенерированный файл действителен как отдельный .sql файл. Поскольку файл не перенаправляется, не передается по конвейеру или иным образом не обрабатывается оболочкой, нет проблемы с необходимостью экранирования каких-либо символов в сгенерированном выводе из-за оболочки. Правила относительно того, что нужно экранировать в файле .sql, конечно, все еще применяются.
Как решать проблемы безопасности, связанные с паролем в командной строке, или в файле my.cnf, и т. Д., Было подробно рассмотрено в других ответах с некоторыми отличными предложениями. Мой любимый ответ , от Дэнни , охватывает это, в том числе, как решить проблему при работе с cron заданиями или чем-то еще.
Чтобы ответить на комментарий (вопрос?) К короткому ответу, который я упомянул: нет, его нельзя использовать с синтаксисом HEREDOC, поскольку дается эта команда оболочки. HEREDOC может использоваться в синтаксисе версии redirection (без опции -Bse), так как перенаправление ввода / вывода - это то, на чем построен HEREDOC. Если вам нужна функциональность HEREDOC, было бы лучше использовать ее при создании файла .sql, даже если это временный файл, и использовать этот файл в качестве «команды» для выполнения с пакетной строкой 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
Помните, что из-за расширения оболочки вы можете использовать переменные оболочки и среды в HEREDOC. Обратной стороной является то, что вы должны избегать каждого обратного удара. MySQL использует их в качестве разделителей для идентификаторов, но оболочка, которая получает строку первой, использует их в качестве разделителей исполняемых команд. Пропустите выход из-за одного обратного удара команд MySQL, и все это взорвется с ошибками. Всю проблему можно решить с помощью цитируемой строки LimitString для 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
Удаление расширения оболочки таким образом избавляет от необходимости избегать обратных символов и других специальных символов оболочки. Это также устраняет возможность использования переменных оболочки и среды внутри него. Это в значительной степени исключает преимущества использования HEREDOC внутри сценария оболочки.
Другой вариант - использовать многострочные строки в кавычках, разрешенные в Bash, с версией синтаксиса пакета (с -Bse). Я не знаю других оболочек, поэтому не могу сказать, работают ли они там тоже. Вам все равно придется использовать это для выполнения более одного .sql файла с командой SOURCE, так как это , а не завершается ;, как и другие команды MySQL, и разрешена только одна за строку Многострочная строка может быть в одинарных или двойных кавычках, что обычно влияет на расширение оболочки. Он также имеет те же предостережения, что и синтаксис HEREDOC для обратных галочек и т. Д.
Потенциально лучшим решением было бы использование языка сценариев Perl, Python и т. Д. Для создания файла .sql, как это делал OP, и SOURCE этого файла с использованием простого командного синтаксиса вверху. Языки сценариев намного лучше работают со строками, чем оболочка, и большинство из них имеют встроенные процедуры для обработки цитирования и экранирования, необходимые при работе с MySQL.