Zoredache está certo: a sobrecarga de stdin é um problema. Pode ser útil se você separou os fluxos de dados alterando o comando remoto entre aspas (após o xx
) para algo como
"exec 4<&0; echo password123 | sudo -S tar --directory=test -xvzf - <&4"
Isso deve levar o stdin ao comando remoto - que é o stdin para o ssh
; isto é, a saída de gzip
–– e embaralha-a no descritor de arquivo 4.
Em seguida, você echo
a senha e canaliza-a para sudo –S
e, em seguida, executa a tar
com a entrada do descritor de arquivo 4, que é o fluxo de dados salvo (a saída de gzip
).
OK, isso provavelmente não funcionará, porque sudo
e tar
estão muito acoplados. Então, tente
"exec 4<&0; echo password123 | sudo -S sh –c \"tar --directory=test -xvzf - <&4\""
Isso deve fornecer a camada extra de separação entre sudo
e tar
para permitir que sudo
leia a senha e tar
leia a saída de gzip
.
OK, lembrei-me de que os descritores de arquivo numerados 3 e superiores no shell não são realmente os descritores de arquivo com esses números; eles são apenas identificadores arbitrários usados dentro do shell. Então eles não transferem de uma instância de shell para outra. Então vamos dar a manivela outra vez, e tente
'myfifo=/tmp/myfifo.$$; mkfifo "$myfifo"; cat > "$myfifo"& sleep 1; echo password123 | sudo -S sh –c "tar --directory=test -xvzf - < \"$myfifo\""; rm "$myfifo"'
Eu coloquei todo o comando remoto em aspas simples para que nenhum dos cifrões fosse interpretado localmente. Eu posso ter citado mais do que realmente precisava.
O sleep 1
é diminuir a probabilidade de uma condição de corrida em que o tar
começa a ler do FIFO antes que o cat
comece a gravar nele.