Dlaczego <lub> jest wymagane do korzystania z / dev / tcp

Podczas próby połączenia /dev/tcp/www.google.com/80, wpisując

/dev/tcp/www.google.com/80

Mówi Bash no such file or directory. Podczas przeglądania kodu innych osób w Internecie używają składni, takiej jak

 3<>/dev/tcp/www.google.com/80

Zauważyłem, że to również działa:

</dev/tcp/www.google.com/80

Dlaczego te symbole są wymagane do wywoływania pewnych rzeczy w bash?

Ponieważ jest to cecha powłoki (ksh, skopiowanej przez bash) i tylko powłoki.

/dev/tcp/...nie są plikami rzeczywistymi, powłoka przechwytuje próby przekierowania do /dev/tcp/...pliku, a następnie wykonuje socket(...);connect(...)(nawiązuje połączenie TCP) zamiast open("/dev/tcp/..."...)(otwiera ten plik) w takim przypadku.

Zauważ, że musi być tak napisane. cat < /dev/./tcp/...lub ///dev/tcp/...nie będzie działać, a zamiast tego spróbuje otworzyć te pliki (które w większości systemów nie istnieją i wystąpi błąd).

Kierunek przekierowania również nie ma znaczenia. Czy używasz 3< /dev/tcp/...lub 3> /dev/tcp/...lub 3<> /dev/tcp/...lub nawet 3>> /dev/tcp/...nie będzie żadnej różnicy, będziesz mógł czytać i pisać do / z tego deskryptora pliku do odbierania / wysyłania danych przez tego gniazda TCP.

Kiedy to zrobisz cat /dev/tcp/..., to nie działa, ponieważ catnie implementuje tej samej specjalnej obsługi, działa open("/dev/tcp/...")podobnie dla każdego pliku (oprócz -), działa tylko powłoka (ksh, tylko bash) i tylko dla celu przekierowań.

To cat -kolejny przykład specjalnie obsługiwanej ścieżki do pliku. Zamiast robić a open("-"), odczytuje bezpośrednio z deskryptora pliku 0 (stdin). cati wiele narzędzi tekstowych to robi, powłoka nie obsługuje przekierowań. Aby odczytać zawartość -pliku, potrzebujesz cat ./-lub cat < -(lub cat - < -). W systemach, które nie mają /dev/stdin, bashzrobi jednak coś podobnego dla przekierowań z tego (wirtualnego) pliku. GNU awkrobi to samo /dev/stdin, /dev/stdout, /dev/stderrnawet na systemach, które mają takie pliki, które mogą powodować pewne niespodzianki na systemach takich jak Linux, gdzie te pliki zachowują się inaczej.

zshma także obsługę gniazd TCP (i strumienia domeny Unix), ale odbywa się to za pomocą wbudowanych ztcp(i zsocket), więc jest mniej ograniczone niż podejście ksh / bash. W szczególności może również działać jako serwer, którego ksh / bash nie może zrobić. Jednak wciąż jest znacznie bardziej ograniczony niż to, co można zrobić w prawdziwym języku programowania.

Wygląda na to, że mylisz pomysły lub czytasz plik i wykonujesz polecenie. Różnica między danymi a instrukcją.

Strona główna Googles nie jest programem wykonywalnym. A gdyby tak było, uruchomienie go nie byłoby bezpieczne.

Znaki przekierowania (w tym <i >) służą do kierowania danych do polecenia.

Możemy to zrobić. cat < /dev/tcp/towel.blinkenlights.nl/23Jednak to nie zadziała, /dev/tcp/www.google.com/80ponieważ ten port nie będzie odpowiadał, dopóki nie wyślemyGET / HTTP/1.0\r\n\r\n

Więc spróbuj

{
  printf >&3 'GET / HTTP/1.0\r\n\r\n'
  cat <&3
} 3<>/dev/tcp/www.google.com/80