Por que <ou> é necessário usar / dev / tcp

Ao tentar ligar /dev/tcp/www.google.com/80, digitando

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

Bash diz no such file or directory. Ao olhar on-line o código de outras pessoas, eles usam sintaxe como

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

Notei que isso também funciona:

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

Por que esses símbolos são necessários para chamar certas coisas no bash?

Porque esse é um recurso do shell (do ksh, copiado pelo bash) e apenas do shell.

/dev/tcp/...não são arquivos reais, o shell intercepta as tentativas de redirecionar para um /dev/tcp/...arquivo e, em seguida, executa socket(...);connect(...)(faz uma conexão TCP) em vez de open("/dev/tcp/..."...)(abre esse arquivo) nesse caso.

Note que tem que ser escrito assim. cat < /dev/./tcp/...ou ///dev/tcp/...não funcionará e, em vez disso, tentará abrir esses arquivos (que na maioria dos sistemas não existem e você receberá um erro).

A direção do redirecionamento também não importa. Se você usa 3< /dev/tcp/...ou 3> /dev/tcp/...ou 3<> /dev/tcp/...ou até mesmo 3>> /dev/tcp/...não vai fazer qualquer diferença, você vai ser capaz de ler e escrever de / para que descritor de arquivo para receber dados / enviar mais que o soquete TCP.

Quando você faz cat /dev/tcp/...isso, isso não funciona porque catnão implementa o mesmo tratamento especial, é open("/dev/tcp/...")semelhante a todos os arquivos (exceto -), apenas o shell (ksh, somente bash), e apenas o destino dos redirecionamentos.

Esse cat -é outro exemplo de um caminho de arquivo tratado especialmente. Em vez de fazer a open("-"), ele lê diretamente do descritor de arquivo 0 (stdin). cate muitos utilitários de texto fazem isso, o shell não faz por seus redirecionamentos. Para ler o conteúdo do -arquivo, você precisa cat ./-, ou cat < -(ou cat - < -). Em sistemas que não possuem /dev/stdin, bashno entanto, fará algo semelhante para redirecionamentos desse arquivo (virtual). GNU awkfaz o mesmo para /dev/stdin, /dev/stdout, /dev/stderrmesmo em sistemas que têm tais arquivos que podem causar algumas surpresas em sistemas como o Linux, onde esses arquivos se comportar de forma diferente.

zshtambém possui suporte a soquetes TCP (e fluxo de domínio Unix), mas isso é feito com um ztcp(e zsocket) built-in, por isso é menos limitado que a abordagem ksh / bash. Em particular, ele também pode atuar como um servidor que o ksh / bash não pode fazer. Ainda é muito mais limitado do que o que você pode fazer em uma linguagem de programação real.

Você parece estar confundindo as idéias ou lendo um arquivo e executando um comando. A diferença entre dados e instrução.

A página inicial do Googles não é um programa executável. E se fosse, não seria seguro executá-lo.

Os caracteres de redirecionamento (incluindo <e >) são usados ​​para direcionar dados para um comando.

Poderíamos fazer. cat < /dev/tcp/towel.blinkenlights.nl/23No entanto, isso não funcionará, /dev/tcp/www.google.com/80pois essa porta não responderá até enviarmosGET / HTTP/1.0\r\n\r\n

Então tente

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