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.