Use this:
cat <(echo command) - | nc host port
The problem is that nc
will close the connection immediately after stdin is closed, which is very quick for a simple my_command
string, and thus never gets the chance to receive a response. (If you pipe a very large file you will see that it might get a response before it's done sending the file).
Enter cat
with -
as second argument: It makes cat
listen on stdin for more content to pipe through after it has sent the contents of the first argument. The first argument is just getting the echo
command through cat
– it could also be a file with your commands a la cat < file - | ...
.
Alternatively do this:
(echo command; while true; do sleep 0.01; echo -n "#"; done) | nc host port
This sends unlimited #
characters on the 2nd line of the input. Using #
works for a bash like remote that would ignore this as a comment. I chose a small wait time of 10 milliseconds here, so it reacts faster on connection end. YMMV.
The downside of that can be that cat
or the while
loop and nc
keep running until you hit ^C
or ^D
on the shell. It really depends on the remote end.
Adding a timeout using -w 1
(OSX netcat) or -i 1
(nmap's ncat) makes it close the connection and nc
after 1 second, but cat
will keep running until you enter some character and the pipe breaks (I think).
However, it works if the remote side will automatically close the connection after receiving and handling the command - this will also end the nc
client and the process piping into it.
This answer is based on this this answer to an identical superuser question.
OpenBSD netcat (Debian patchlevel 1.105-7ubuntu1)
version; and at the remote end istelegram-cli
on the same machine. – Ariyan Jun 13 '16 at 02:46netcat
receives the EOF on STDIN, that it immediately shuts down both sides of the socket instead of doing a half-close and waiting for the remote side to close its end. Ifsocat
is an option, I would highly recommend it instead. There's only onesocat
, so you don't have the portability issues with there being a dozen different flavors of it, it behaves a lot more sanely, and is highly configurable. – phemmer Jun 13 '16 at 03:34socat
and same thing happens with it !!! interesting point is that both netcat & socat in using piped input exit immediately while in interactive mode it takes a time to get response; second, sometelegram-cli
commands work correctly (e.g.help
); actually it seems commands that need to communicate over network has this problem! – Ariyan Jun 13 '16 at 03:50-t
option ofsocat
. If that doesn't solve it, I'd look at an strace or a packet capture then. It's likely that the issue is the remote (telegram-cli
) end, and it shutting down the connection as soon as it receives the EOF reading from the client, even if it has pending responses to write. – phemmer Jun 13 '16 at 04:57-t
had no effect! – Ariyan Jun 14 '16 at 01:11stdin
, while the second variant terminatesstdin
as soon asecho
has finished. I guessnetcat
terminates once it sees EOF onstdin
. – U. Windl Feb 03 '22 at 22:55