He encontradoPor aquíde verificar si un host es accesible en un puerto determinado, sin embargo, solo estoy interesado en el código de estado del comando, por lo tanto, estoy intentando algo como esto:
[CptBartender@somewhere ~]$ <dev/tcp/host/port ; echo $?
0
Esto funciona bien si pruebo en un puerto abierto, sin embargo, si reviso un puerto cerrado, obtengo:
[CptBartender@somewhere ~]$ <dev/tcp/host/blocked_port ; echo $?
-bash: connect: Connection refused
-bash: /dev/tcp/host/blocked_port: Connection refused
1
Ahora mi siguiente paso fue intentar descartar los resultados del primer comando, así que intenté:
[CptBartender@somewhere ~]$ <dev/tcp/host/blocked_port >/dev/null/ 2>&1; echo $?
-bash: connect: Connection refused
-bash: /dev/tcp/host/blocked_port: Connection refused
1
Misma salida. Mis preguntas son: ¿por qué el primer comando imprime algún resultado y cómo puedo evitar que lo haga?
Respuesta1
no es eldominioeso es salida de impresión. no tienescualquiercomando – < /dev/tcp/…es simplemente normalredirección de entraday es procesado por el propio shell.
(Y no sólo eso, sino que las redirecciones se procesan de izquierda a derecha, por lo que la <redirección se procesaantesel 2>&1indicado, por lo que no se pudo redirigirde todos modos.)
Puede solucionar este problema ejecutando el "comando" en un subshell. Por ejemplo:
( </dev/tcp/$host/$port ) 2>/dev/null
En realidad, parece que en este caso no se requiere una subcapa; un grupo de comandos funcionará incluso si está dentro del mismo proceso; aún obliga a que las redirecciones "externas" se procesen primero:
{ </dev/tcp/$host/$port; } 2>/dev/null
Nota al margen: /dev/tcpes una ruta mágica que es manejada por el propio bash; en realidad no existe en /dev de Linux, pero se puede usar con redirecciones de bash. Sin embargo, este truco no funcionará con #!/bin/sh, y todavía existe la posibilidad de que no funcione con bash en algunos sistemas más antiguos (que solían deshabilitar esta función) o en algunos sistemas que no son Linux.