GNU/Linux >> LINUX-Kenntnisse >  >> Linux

Warum sind < oder > erforderlich, um /dev/tcp

Denn das ist ein Feature der Shell (von ksh, kopiert von bash) und nur der Shell.

/dev/tcp/... keine echten Dateien sind, fängt die Shell die Versuche ab, auf /dev/tcp/... umzuleiten Datei und macht dann einen socket(...);connect(...) (stellt eine TCP-Verbindung her) anstelle von open("/dev/tcp/..."...) (Öffnen dieser Datei) in diesem Fall.

Beachten Sie, dass es so geschrieben werden muss. cat < /dev/./tcp/... oder ///dev/tcp/... funktioniert nicht und versucht stattdessen, diese Dateien zu öffnen (die auf den meisten Systemen nicht existieren und Sie erhalten eine Fehlermeldung).

Auch die Richtung der Umleitung spielt keine Rolle. Ob Sie 3< /dev/tcp/... verwenden oder 3> /dev/tcp/... oder 3<> /dev/tcp/... oder sogar 3>> /dev/tcp/... keinen Unterschied machen, Sie können diesen Dateideskriptor sowohl lesen als auch schreiben, um Daten über diesen TCP-Socket zu empfangen/zu senden.

Wenn Sie cat /dev/tcp/... machen , das geht nicht, weil cat implementiert nicht dieselbe spezielle Behandlung, sondern open("/dev/tcp/...") wie für jede Datei (außer - ), nur die Shell (nur ksh, bash) und nur für das Ziel von Umleitungen.

Diese cat - ist ein weiteres Beispiel für einen speziell gehandhabten Dateipfad. Anstatt einen open("-") zu machen , liest es direkt aus dem Dateideskriptor 0 (stdin). cat und viele Textdienstprogramme tun dies, die Shell nicht für ihre Umleitungen. Um den Inhalt von - zu lesen Datei benötigen Sie cat ./- , oder cat < - (oder cat - < - ). Auf Systemen ohne /dev/stdin , bash wird jedoch etwas Ähnliches für Umleitungen von dieser (virtuellen) Datei tun. GNU awk macht dasselbe für /dev/stdin , /dev/stdout , /dev/stderr sogar auf Systemen, die solche Dateien haben, was auf Systemen wie Linux, wo sich diese Dateien anders verhalten, einige Überraschungen hervorrufen kann.

zsh hat auch TCP-Socket-Unterstützung (und Unix-Domain-Stream), aber das wird mit einem ztcp erledigt (und zsocket ) builtins, also weniger eingeschränkt als der ksh/bash-Ansatz. Insbesondere kann es auch als Server fungieren, was ksh/bash nicht kann. Es ist jedoch immer noch viel eingeschränkter als das, was Sie in einer echten Programmiersprache tun können.


Sie scheinen die Ideen zu verwirren oder eine Datei zu lesen und einen Befehl auszuführen. Der Unterschied zwischen Daten und Anweisungen.

Die Startseite von Google ist kein ausführbares Programm. Und wenn ja, wäre es nicht sicher, es auszuführen.

Die Umleitungszeichen (einschließlich < und > ), werden verwendet, um Daten in einen Befehl zu leiten.

Wir könnten cat < /dev/tcp/towel.blinkenlights.nl/23 machen Dies funktioniert jedoch nicht für /dev/tcp/www.google.com/80 da dieser Port nicht antwortet, bis wir GET / HTTP/1.0\r\n\r\n senden

Versuchen Sie es also

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

Linux
  1. Wie behandelt Linux mehrere aufeinanderfolgende Pfadtrennzeichen (/home////username///file)?

  2. Wie portabel sind /dev/stdin, /dev/stdout und /dev/stderr?

  3. Wann sollte /dev/random vs. /dev/urandom verwendet werden?

  4. Debian – /var, /home auf separate Partition verschieben?

  5. So ordnen Sie /dev/sdX- und /dev/mapper/mpathY-Geräte vom /dev/dm-Z-Gerät zu

tty (/dev/tty ) vs. pts (/dev/pts) unter Linux

DD von /dev/zero nach /dev/null ... was eigentlich passiert

Kernel:/dev/kmem und /dev/mem deaktivieren

Wie Linux /dev/tty und /dev/tty0 verwendet

Ist es falsch, /dev/random unter Linux mit /dev/urandom zu verknüpfen?

echo oder print /dev/stdin /dev/stdout /dev/stderr