Estou escrevendo um script de shell bash que é executado em um servidor de salto. Isso tem um parâmetro, que representa uma string a ser pesquisada. Este parâmetro é trabalhado em um comando '-surrounded (substituição de comando) que faz um grep para o parâmetro de busca em um grupo de arquivos em um diretório e canaliza o resultado para wc -l . Isso é então trabalhado em uma string entre aspas que é passada como um parâmetro de comando:
ssh server "[grep command]"
Esse comando ssh é executado em um loop que percorre todos os servidores que queremos verificar.
Conseguir todas as citações corretamente para que cada elemento não seja avaliado até o momento adequado foi uma grande dor, mas eu quase consegui essa coisa louca trabalhando.
Tudo é passado para o servidor apropriado pelo ssh, mas quando o comando é executado no servidor, o resultado é
bash: /bin/echo "26520 instances of [xyz]": No such file or directory
O 26520 é o resultado da execução bem-sucedida
/bin/grep xyz /path/to/logfiles/*access*|wc -l
que foi passado como parte do comando via ssh:
ssh server [command]
se eu realmente fizer ssh para um dos servidores remotos e executar
$ /bin/echo "26490 instances of [xyz]"
26520 instances of [xyz]
bash, claro que não tem problema.
se eu realmente fizer ssh para um dos servidores remotos e executar
$ /bin/echo "'/bin/grep xyz /path/to/logfiles/*access*|wc -l' instances of [xyz]"
26520 instances of [xyz]
bash também não tem problema.
Mas quando o comando vem através do ssh ele tem esse problema - mesmo que o comando grep tenha sido executado e produzido o resultado correto
bash: /bin/echo "26520 instances of [xyz]": No such file or directory
O que exatamente é o bash objetando e como posso contornar isso?
UPDATE : para simplificar, acho que posso replicar o problema por uma linha de comando de uma linha no servidor local , abstraindo todas as complicações decorrentes dos scripts, substituições de variáveis, etc.
$ ssh {remoteserver} "echo '/bin/grep xyz /path/to/logfiles/*access*|wc -l'"
grep: /path/to/logfiles/*access*: No such file or directory
26520
Novamente, o bash está reclamando sobre esse arquivo (ele existe mesmo assim) e, em seguida, vai em frente e executa o comando grep e imprime o resultado correto.
Na verdade, resolvi o problema agora reescrevendo meu script para gravar todos os comandos dos servidores remotos em um arquivo no servidor local, depois de resolver os parâmetros da linha de comando e, em seguida, canalizando o conteúdo do arquivo para ssh:
echo ... > commandfile
cat commandfile | ssh -T ${SERVER}
Eu também tentei o <
Mas eu ainda gostaria de saber o que bash estava se opondo.
Rodando
ssh {remoteserver} "echo '/bin/grep xyz /path/to/logfiles/*access*|wc -l'"
leva a executar o subcomando em seu computador local, não o remoto. Pode ser simplesmente verificado usando
$ ssh host "echo 'hostname'"
the local hostname
se você quiser executar o subcomando no servidor remoto, use apóstrofos
$ ssh host 'echo 'hostname''
the remote hostname
mas o erro na atualização é diferente do original ...
ssh server "[grep command]"
Substituições de variáveis e comandos ( $variable , $(command) , 'command' ) são executadas entre aspas duplas, portanto, se qualquer $ ou ' aparecer em [grep command] , ela será executada pelo shell local antes de invocar %código%. Então, uma vez que as substituições tenham sido realizadas (executando o comando ssh localmente), grep é chamado, para ssh uma string no host remoto.
Coloque o comando para executar no host remoto entre aspas simples (ou seja, apóstrofos):
ssh server '[grep command]'
Por simplicidade, não inclua nenhuma aspas simples no comando. Se você realmente precisar de uma cota única, poderá incluí-la como echo (aspas simples, contrabarra, aspas simples, aspas simples).
Tags ssh bash command-substitution