Eu tenho em pull_news.sh (declarações de variáveis omitidas):
dump_table () {
mysqldump --user=${REMOTE_USERNAME} --password=${REMOTE_PASSWORDS} --host=${REMOTE_HOST} --port=${REMOTE_PORT} --single-transaction --lock-tables=false $@
}
pull_news(){
dump_table --set-gtid-purged=OFF --where="INFOCODE IN (SELECT INFOCODE FROM info_an_newsrelation WHERE MKTPOSTFIX = '.OC')" ${REMOTE_DBNAME} info_an_newscontent > ${DUMPFILE}
}
pull_news
Depois
$ ./pull_news.sh
Eu obtive
mysqldump: Got error: 1044: Access denied for user 'user'@'%' to database 'in' when selecting the database
O problema desapareceu se eu remover a cláusula where, então parece-me que, por algum motivo desconhecido, o shell pegou apenas a primeira palavra da minha cláusula where e analisou a segunda palavra (the IN
) como um nome de banco de dados.
Depois troquei por
--where="\"INFOCODE IN (SELECT INFOCODE FROM info_an_newsrelation WHERE MKTPOSTFIX = '.OC')\""
mas não funcionou. Não sei o que fazer agora, qualquer ajuda é bem vinda...
O não citado
$@
é o problema. Ele se expande para todos os argumentos da função e, depois disso, os torna sujeitos a divisão de palavras (e globbing). Coloque entre aspas:As outras variáveis também devem ser citadas (
"${REMOTE_USERNAME}"
) apenas por uma questão de princípio, embora os nomes de usuários e nomes de banco de dados provavelmente não contenham espaços em branco (ou caracteres glob)A string que você está passando como argumento não contém aspas duplas. Após o processamento da cotação (remoção) pelo shell, é apenas a string
--where=INFOCODE IN (SELECT ... = '.OC')
e é assim que amysqldump
veria, se você a iniciasse diretamente em vez de por meio da outra função. Colocar as aspas"$@"
mantém assim.Claro, a resposta para a pergunta no título, você pode passar aspas duplas literais escapando-as da barra invertida ou colocando-as entre aspas simples, como em qualquer outro comando: