web-dev-qa-db-fra.com

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

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

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

Bash dit 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?

linuxbashio-redirectiondevices
13
john doe

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 fichier /dev/tcp/... Puis fait une socket(...);connect(...) (crée un TCP = connexion) au lieu d'une open("/dev/tcp/..."...) (ouverture de 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 même 3>> /dev/tcp/... Ne fera aucune différence, vous pourrez lire et écrire à partir de/à ce descripteur de fichier pour recevoir/envoyer des données sur ce TCP socket.

Lorsque vous faites cat /dev/tcp/..., Cela ne fonctionne pas car cat n'implémente pas la même gestion spéciale, il fait une open("/dev/tcp/...") comme pour chaque fichier (sauf -), Seul le Shell (ksh, bash uniquement) le fait, et uniquement pour la cible des redirections.

Ce cat - Est un autre exemple de chemin de fichier géré spécialement. Au lieu de faire une open("-"), il lit directement à partir du descripteur de fichier 0 (stdin). cat et 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'ont pas /dev/stdin, bash fera cependant quelque chose de similaire pour les redirections à partir de ce fichier (virtuel). GNU awk fait la même chose pour /dev/stdin, /dev/stdout, /dev/stderr Même sur les systèmes qui ont de tels fichiers qui peuvent provoquer des surprises sur des systèmes comme Linux où ces fichiers se comportent différemment.

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

29
Stéphane Chazelas

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 dans une commande.

Nous pourrions faire cat < /dev/tcp/towel.blinkenlights.nl/23 Cependant, cela ne fonctionnera pas pour /dev/tcp/www.google.com/80 car ce port ne répondra pas tant que nous n'aurons pas envoyé GET / 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
4
ctrl-alt-delor