Pourquoi faut-il <ou> utiliser / dev / tcp

Lorsque vous essayez d'appeler /dev/tcp/www.google.com/80, en tapant

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

Dit Bash no such file or directory. Lorsqu'ils consultent le code d'autres personnes en ligne, ils utilisent une syntaxe telle que

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

J'ai remarqué que cela fonctionne aussi:

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

Pourquoi ces symboles sont-ils nécessaires pour appeler certaines choses en bash?

Parce que c'est une fonctionnalité du shell (de ksh, copié par bash), et du shell uniquement.

/dev/tcp/...ne sont pas de vrais fichiers, le shell intercepte les tentatives de redirection vers un /dev/tcp/...fichier et fait ensuite socket(...);connect(...)(établit une connexion TCP) au lieu de open("/dev/tcp/..."...)(ouvrir ce fichier) dans ce cas.

Notez qu'il doit être orthographié comme ça. cat < /dev/./tcp/...ou ///dev/tcp/...ne fonctionnera pas, et tentera d'ouvrir ces fichiers à la place (qui sur la plupart des systèmes n'existent pas et vous obtiendrez une erreur).

La direction de la redirection n'a pas non plus d'importance. Que vous utilisiez 3< /dev/tcp/...ou 3> /dev/tcp/...ou 3<> /dev/tcp/...ou que 3>> /dev/tcp/...cela ne fasse aucune différence, vous pourrez à la fois lire et écrire depuis / vers ce descripteur de fichier pour recevoir / envoyer des données sur ce socket TCP.

Lorsque vous le faites cat /dev/tcp/..., cela ne fonctionne pas car catn'implémente pas la même gestion spéciale, il fait la même chose open("/dev/tcp/...")pour chaque fichier (sauf -), seul le shell (ksh, bash uniquement) le fait, et uniquement pour la cible des redirections.

C'est cat -un autre exemple de chemin de fichier géré spécialement. Au lieu de faire un open("-"), il lit directement à partir du descripteur de fichier 0 (stdin). catet de nombreux utilitaires de texte le font, le shell ne le fait pas pour ses redirections. Pour lire le contenu du -fichier, vous avez besoin de cat ./-, ou cat < -(ou cat - < -). Sur les systèmes qui n'en ont pas /dev/stdin, bashfera cependant quelque chose de similaire pour les redirections à partir de ce fichier (virtuel). GNU awkfait la même chose pour /dev/stdin, /dev/stdout, /dev/stderrmême sur des systèmes qui ont des ces fichiers qui peuvent causer des surprises sur des systèmes comme Linux où ces fichiers se comportent différemment.

zshprend également en charge les sockets TCP (et flux de domaine Unix), mais cela se fait avec un ztcp(et zsocket) intégré, il est donc moins limité que l'approche ksh / bash. En particulier, il peut également agir comme un serveur que ksh / bash ne peut pas faire. C'est encore beaucoup plus limité que ce que vous pouvez faire dans un vrai langage de programmation.

Vous semblez confondre les idées ou lire un fichier et exécuter une commande. La différence entre les données et l'instruction.

La première page de Google n'est pas un programme exécutable. Et si c'était le cas, il ne serait pas sûr de l'exécuter.

Les caractères de redirection (y compris <et >) sont utilisés pour diriger les données vers une commande.

Nous pourrions faire cat < /dev/tcp/towel.blinkenlights.nl/23mais cela ne fonctionnera pas /dev/tcp/www.google.com/80car ce port ne répondra pas tant que nous n'enverrons pasGET / HTTP/1.0\r\n\r\n

Alors essayez

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