Wysyłasz zawartość pliku tekstowego na serwer za pomocą programu Netcat?


13

Na porcie 5144 nasłuchuje proces demona, którego nie mogę zmodyfikować.

Chcę użyć netcata, aby wysłać zawartość pliku tekstowego na serwer, ale powoduje netcatto zawieszenie terminala, dopóki nie naciśnie Ctrl+ C:

cat file.txt | nc -u 127.0.0.1 5144

Jedynym sposobem, w jaki mogę go uruchomić, jest nc -u 127.0.0.1 5144ręczne uruchomienie i skopiowanie / wklejenie zawartości pliku.

Jakieś pomysły?


Uwaga:

  1. cat file.txt | ...prowadzi do bash: ...: command not foundi mogę nadal korzystać z terminala
  2. używanie nc -u 127.0.0.1 5144 < file.txtprowadzi do takiego samego zachowania jak używanie | powyżej

Co się stanie, kiedy powiesz cat file.txt | …? Jak o nc -u 127.0.0.1 5144 < file.txt?
Scott,

czy potrzebujesz użyć -u? Czy próbowałeś też drugiej strony, nc -l -p? i próbowałeś nc -p? (jest jeden nc, który używa -l -p, i jeden, który używa -p bez -l). Pokazałeś tylko jedną stronę, stronę klienta / inicjującą. Co robisz po stronie serwera? Spróbuj, testując, aby nc nasłuchiwał na porcie 1234 i sprawdził, czy cat ... | nc ... działa. Nigdy wcześniej go nie widziałem, więc może jest to słaby, ale może jest to coś szczególnego dla tego konkretnego demona, który nie akceptuje rzeczy zaspokajanych.
barlop

Nie mogę zmodyfikować demona. @Scott: bash: ...: command not foundi użycie „<file.txt” robi to samo, co | operator (netcat po prostu się zawiesza)
Amil

Czy możesz być bardziej precyzyjny? Czy to mówi „ bash: ...: command not found”? A może mówi „ bash: cat: command not found” lub „ bash: nc: command not found”? A następnie czy następnie wychodzi do monitu powłoki, czy też zawiesza się? (Zachęcam do edycji pytania w celu dodania tych szczegółów, więc osoby w Australii, które właśnie się budzą, nie muszą czytać wszystkich tych komentarzy, aby dowiedzieć się, jakie są twoje objawy.)
Scott

@Scott: Dzięki, zintegrowałem moje odpowiedzi na twoje pytania z pierwotnym pytaniem. Jakieś pomysły?
Amil

Odpowiedzi:


7

Jeśli używasz GNU w wersji netcat, możesz użyć flagi -c, aby zamknąć połączenie na EOF.

-c, --close zamknij połączenie EOF ze standardowego wejścia

Jeśli używasz oryginalnej wersji narzędzia, możesz użyć flagi -q.

-q sek. zakończone po EOF na stdin i opóźnieniu sek

Przykładem oryginalnej wersji jest:

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

Dodałem „-q 0” do twojego oryginalnego polecenia. To zamyka połączenie po wysłaniu pliku.


Aby odróżnić: oryginalna wersja jest wersją, która wymaga określenia -l -p <port>do słuchania. Wersja GNU po prostu bierze -l <port>.
tueftl

1

Zakładając, że po wysłaniu połączenia EOF pozostanie bezczynny, możesz użyć -w timeoutopcji, która działa tak timeout, jakby była równa zero (w przeciwieństwie do głupiej -qopcji ...)

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

0

Jeśli przenosisz z FreeBSD do Windows:

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

-N wyłączy gniazdo sieciowe po EOF

Windows: nc -l -p 5144 > output.txt

-lprzestanie nasłuchiwać po zamknięciu połączenia (w przeciwieństwie do -L)

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.