Отправка содержимого текстового файла на сервер с помощью netcat?


13

На порту 5144 прослушивается процесс-демон, который я не могу изменить.

Я хочу использовать netcat для отправки содержимого текстового файла на сервер, но это приводит netcatк зависанию терминала, пока я не нажму Ctrl+ C:

cat file.txt | nc -u 127.0.0.1 5144

Единственный способ заставить его работать - это запустить nc -u 127.0.0.1 5144и скопировать / вставить содержимое файла вручную.

Есть идеи?


Также обратите внимание:

  1. cat file.txt | ...приводит к, bash: ...: command not foundи я могу продолжать использовать терминал
  2. использование nc -u 127.0.0.1 5144 < file.txtприводит к тому же поведению, что и использование | над

Что происходит, когда вы говорите cat file.txt | …? Как насчет nc -u 127.0.0.1 5144 < file.txt?
Скотт

вам нужно использовать -u? Кроме того, вы пробовали другую сторону, nc -l -p? а ты пробовал nc -p? (есть один nc, который использует -l -p, и один, я думаю, который использует -p без -l). Вы показали только одну сторону, клиент / инициатор. Что вы делаете для серверной части? Попробуйте в качестве теста, заставив nc прослушивать порт 1234 и посмотреть, cat ... | нк ... работает к этому. Я никогда не видел этого раньше, так что, возможно, это слабое место, но, может быть, это что-то особенное для этого конкретного демона, который не принимает поступившие вещи.
Барлоп

Я не могу изменить демона. @Scott: bash: ...: command not foundи использование «<file.txt» делает то же самое, что и | оператор (netcat просто зависает)
Амил

Можете ли вы быть более точным? Это говорит « bash: ...: command not found»? Или это говорит « bash: cat: command not found» или « bash: nc: command not found»? И затем он выходит из командной строки или зависает? (Я призываю вас отредактировать вопрос, чтобы добавить эти подробности, чтобы людям в Австралии, которые только что проснулись, не нужно было читать все эти комментарии, чтобы узнать, каковы ваши симптомы.)
Скотт,

@ Скотт: Спасибо, я интегрировал свои ответы на ваши вопросы в оригинальный вопрос. Есть идеи?
Амил

Ответы:


7

Если вы используете GNU-версию netcat, вы можете использовать флаг -c, чтобы закрыть соединение в EOF.

-c, - закрыть закрытое соединение на EOF от stdin

Если вы используете оригинальную версию инструмента, вы можете использовать флаг -q.

-q секунд выйти после EOF на стандартный ввод и задержка секунд

Пример для оригинальной версии:

cat file.txt | nc -u -q 0 127.0.0.1 5144

Я добавил «-q 0» к вашей исходной команде. Это закрывает соединение после отправки файла.


Чтобы отличить: оригинальная версия та, которую требуется указать -l -p <port>для прослушивания. Версия GNU просто берет -l <port>.
вторник

1

Предполагая, что после отправки EOF соединение будет бездействовать, вы можете использовать -w timeoutопцию, которая работает, чтобы timeoutбыть равной нулю (в отличие от глупой -qопции ...)

cat file.text | nc -u localhost 4300 -w0

0

Если вы переходите с FreeBSD на Windows:

FreeBSD: cat file.txt | nc -N 10.0.0.5 5144

-N отключит сетевой сокет после EOF

Окна: nc -l -p 5144 > output.txt

-lпрекратит прослушивание при закрытом соединении (в отличие от -L)

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.