Я нашелСюдапроверки доступности хоста на заданном порту, однако меня интересует только код состояния команды, поэтому я пробую что-то вроде этого:
[CptBartender@somewhere ~]$ <dev/tcp/host/port ; echo $?
0
Это работает нормально, если я пробую на открытом порту, однако если я проверяю закрытый порт, я получаю:
[CptBartender@somewhere ~]$ <dev/tcp/host/blocked_port ; echo $?
-bash: connect: Connection refused
-bash: /dev/tcp/host/blocked_port: Connection refused
1
Теперь моим следующим шагом было попытаться отбросить выходные данные первой команды, поэтому я попробовал:
[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
Тот же вывод. У меня вопросы: почему первая команда вообще выводит какой-либо вывод и как мне этого не допустить?
решение1
Это не токомандаэто вывод на печать. У вас нетлюбойкоманда – < /dev/tcp/…это просто обычнаяперенаправление вводаи обрабатывается самой оболочкой.
(И не только это, но и перенаправления обрабатываются слева направо, поэтому перенаправление <обрабатываетсядоодин 2>&1, поэтому его нельзя перенаправитьв любом случае.)
Вы можете обойти это, запустив "команду" в подоболочке. Например:
( </dev/tcp/$host/$port ) 2>/dev/null
На самом деле, похоже, что в этом случае подоболочка не требуется; группа команд будет работать, даже если она находится в том же процессе — она все равно заставляет сначала обрабатывать «внешние» перенаправления:
{ </dev/tcp/$host/$port; } 2>/dev/null
Примечание: /dev/tcpэто магический путь, который обрабатывается самим bash – он на самом деле не существует в /dev Linux, но может использоваться с перенаправлениями bash. Однако этот трюк не будет работать с #!/bin/sh, и все еще есть вероятность, что он не будет работать с bash на некоторых старых системах (которые раньше отключали эту функцию) или на некоторых не-Linux системах.