GNU/Linux >> Linux Esercitazione >  >> Linux

Perché sono necessari < o > per usare /dev/tcp

Perché questa è una caratteristica della shell (di ksh, copiata da bash) e solo della shell.

/dev/tcp/... non sono file reali, la shell intercetta i tentativi di reindirizzamento a un /dev/tcp/... file e quindi esegue un socket(...);connect(...) (crea una connessione TCP) invece di un open("/dev/tcp/..."...) (aprendo quel file) in quel caso.

Nota che deve essere scritto così. cat < /dev/./tcp/... o ///dev/tcp/... non funzionerà e tenterà invece di aprire quei file (che sulla maggior parte dei sistemi non esistono e riceverai un errore).

Anche la direzione del reindirizzamento non ha importanza. Se usi 3< /dev/tcp/... o 3> /dev/tcp/... o 3<> /dev/tcp/... o anche 3>> /dev/tcp/... non farà alcuna differenza, sarai in grado sia di leggere che di scrivere da/a quel descrittore di file per ricevere/inviare dati su quel socket TCP.

Quando esegui cat /dev/tcp/... , non funziona perché cat non implementa la stessa gestione speciale, fa un open("/dev/tcp/...") come per ogni file (eccetto - ), lo fa solo la shell (solo ksh, bash) e solo per l'obiettivo dei reindirizzamenti.

Quel cat - è un altro esempio di un percorso di file gestito in modo speciale. Invece di fare un open("-") , legge direttamente dal descrittore di file 0 (stdin). cat e molte utilità di testo lo fanno, la shell non lo fa per i suoi reindirizzamenti. Per leggere il contenuto del - file, hai bisogno di cat ./- o cat < - (o cat - < - ). Sui sistemi che non hanno /dev/stdin , bash farà comunque qualcosa di simile per i reindirizzamenti da quel file (virtuale). GNU awk fa lo stesso per /dev/stdin , /dev/stdout , /dev/stderr anche su sistemi che hanno tali file che possono causare alcune sorprese su sistemi come Linux dove quei file si comportano in modo diverso.

zsh ha anche il supporto socket TCP (e flusso di dominio Unix), ma questo è fatto con un ztcp (e zsocket ), quindi è meno limitato rispetto all'approccio ksh/bash. In particolare, può anche fungere da server cosa che ksh/bash non può fare. È comunque molto più limitato di quello che puoi fare in un vero linguaggio di programmazione.


Sembra che tu stia confondendo le idee o leggendo un file ed eseguendo un comando. La differenza tra dati e istruzioni.

La prima pagina di Google non è un programma eseguibile. E se lo fosse, non sarebbe sicuro eseguirlo.

I caratteri di reindirizzamento (incluso < e > ), vengono utilizzati per indirizzare i dati in un comando.

Potremmo fare cat < /dev/tcp/towel.blinkenlights.nl/23 Tuttavia questo non funzionerà per /dev/tcp/www.google.com/80 poiché questa porta non risponderà finché non invieremo GET / HTTP/1.0\r\n\r\n

Quindi prova

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

Linux
  1. Quando dovrei usare /dev/shm/ e quando dovrei usare /tmp/?

  2. DD da /dev/zero a /dev/null... cosa succede realmente

  3. Linux:differenza tra /dev/console , /dev/tty e /dev/tty0

  4. kernel:disabilitare /dev/kmem e /dev/mem

  5. È sbagliato collegare /dev/random a /dev/urandom su Linux?

tty (/dev/tty ) vs pts (/dev/pts) in Linux

Come mappare il dispositivo /dev/sdX e /dev/mapper/mpathY dal dispositivo /dev/dm-Z

Cosa sono i file /dev/zero e /dev/null in Linux

Come codificare in base64 /dev/random o /dev/urandom?

Come Linux usa /dev/tty e /dev/tty0

echo o print /dev/stdin /dev/stdout /dev/stderr