Zoredache is right: the overloading of stdin is a problem. It might help if you separated the data streams by changing the quoted remote command (after the
xx) to something like
"exec 4<&0; echo password123 | sudo -S tar --directory=test -xvzf - <&4"
This should take the stdin to the remote command –– which is the stdin to the
ssh; i.e., the output from
gzip –– and shuffle it over to file descriptor 4.
echo the password and pipe it into
sudo –S, and then run the
tar with input from file descriptor 4, which is the saved data stream (the output from
OK, that probably won’t work, because
tar are too tightly coupled. So, instead, try
"exec 4<&0; echo password123 | sudo -S sh –c \"tar --directory=test -xvzf - <&4\""
That should provide the extra layer of separation between
tar to allow
sudo to read the password and
tar to read the output from
OK, it comes back to me that the file descriptors numbered 3 and higher in the shell are not really the file descriptors with those numbers; they are just arbitrary identifiers used within the shell. So they don’t transfer from one shell instance to another.
So let’s give the crank another turn, and try
'myfifo=/tmp/myfifo.$$; mkfifo "$myfifo"; cat > "$myfifo"& sleep 1; echo password123 | sudo -S sh –c "tar --directory=test -xvzf - < \"$myfifo\""; rm "$myfifo"'
I put the entire remote command into single quotes so none of the dollar signs would be interpreted locally. I may have quoted more than I really needed to.
sleep 1 is to decrease the probability of a race condition where the
tar starts reading from the FIFO before the
cat starts writing to it.