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 puis fait un socket(...);connect(...) (établit une connexion TCP) au lieu d'un 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 n'existent pas sur la plupart des systèmes 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 à la fois lire et écrire depuis/vers ce descripteur de fichier pour recevoir/envoyer des données sur ce socket TCP.
Lorsque vous faites cat /dev/tcp/... , cela ne fonctionne pas car cat n'implémente pas la même gestion spéciale, il fait un 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 un 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 de même pour /dev/stdin , /dev/stdout , /dev/stderr même sur les systèmes qui ont de tels fichiers, ce qui peut causer 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 un ztcp (et zsocket ) builtins, il est donc moins limité que l'approche ksh/bash. En particulier, il peut également agir en tant que serveur, ce que ksh/bash ne peut pas faire. C'est quand même 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 page d'accueil 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 (dont < 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