echo command | netcat host port
Isso faz com que o comando seja enviado para o host remoto e alguns dados sejam lidos de volta. Mas depois de alguns segundos, a conexão é fechada. O parâmetro -w não mudou nada. Estou usando o netcat v1.10 no SuSE 10.1.
Isso funciona com o comando nc no OS X (supondo que o comando que você deseja enviar esteja em um arquivo):
cat file - | nc host port
(Essencialmente, cat despeja o conteúdo do arquivo no stdout e depois espera por você no stdin).
Por extensão, se você quiser enviar o comando a partir do próprio shell, você pode fazer isso:
cat <(echo command) - | nc host port
Com nc no Ubuntu:
nc -q -1 host port
Na página Ubuntu nc man :
-q seconds
after EOF on stdin, wait the specified number of seconds and then quit. If seconds is negative, wait forever.
Observe que as opções nc disponíveis variam muito entre distribuições, portanto, isso pode não funcionar no seu (OpenSUSE).
Eu achei:
echo command | netcat host port -
Meu colega de trabalho sabia disso. Eu não vejo isso na documentação.
Eu não acho que você vai conseguir isso com netcat ou socat. Acabei de fazer extensos ajustes com ambos, e socat parecia o mais promissor.
Consegui configurar o socat para conectar-me à porta TCP remota e escutar em um soquete de domínio unix local (em teoria, o link poderia ser mantido ligado o tempo todo), mas assim que o processo local fosse desconectado do soquete unix (outra socat ligando o socket unix a stdin / out) fechou a sessão TCP socat.
O problema aqui é que cada conexão através de netcat / socat faz uma nova conexão de fluxo TCP ao servidor, e fecha aquela sessão de fluxo TCP quando a extremidade local desconecta.
Eu acho que você provavelmente terá que escrever algum software de proxy personalizado para isso que abra a conexão TCP para o final remoto e, em seguida, escuta localmente em um socket / pipe / fifo ou qualquer outra coisa e, em seguida, apenas envia os dados para baixo tubo TCP existente e retorna os resultados.
O método de Georges funciona bem em um shell interativo, mas não ajuda com scripts, quando você está, por exemplo, chamando seu script como nohup ./script & .
Eu achei que substituir o stdin por um dummy fifo ajuda.
mkfifo dummy
cat command.txt dummy | nc host port
Como nada grava no fifo, depois de gerar o arquivo, cat trava indefinidamente.
Será que a conexão está fechada na outra extremidade do soquete?
Por padrão, nc fecha a conexão após a conclusão, se você não disser explicitamente a ele para ficar escutando (com a opção -k ):
-k Forces nc to stay listening for another connection after its current
connection is completed. It is an error to use this option without the
-l option.
Veja man nc.1 .
Estou transmitindo dados com sucesso entre duas máquinas como esta:
remetente:
while (true); do
echo -n "$RANDOM " | nc <host> <port>
done
receptor:
nc -kl <port>
socat do shut-none deve ajudar aqui:
Changes the (address dependent) method of shutting down the write part of a connection to not do anything.
Provavelmente, você também precisará substituir o período de tempo limite padrão usando -t <timeout> , caso contrário, o soquete será fechado após 0,5 s. Esta opção sobrescreve o comportamento padrão, que é:
When one of the streams effectively reaches EOF, the closing phase begins. Socat transfers the EOF condition to the other stream, i.e. tries to shutdown only its write stream, giving it a chance to terminate gracefully. For a defined time socat continues to transfer data in the other direction, but then closes all remaining channels and terminates.
Então, um comando como:
echo 'blah' | socat -t 10 stdio tcp:<addr>:<port>,shut-none
manterá o socket aberto por 10s após o envio do 'blah'.
Seu comando termina, se o host remoto fechar a conexão (ou não puder ser acessado) ou o comando antes do pipe ser finalizado (enquanto o netcat ainda envia o restante de sua fila de entrada).
Tags netcat