Исключить ошибку из вывода сценария оболочки

Я хотел бы опустить ошибку из этого оператора IF, если эхо ICMP не удается.

Пример кода:

if ping -q -c 1 -W 1 1.2.3.4 >/dev/null; then
  echo -e "PING OK"
else
  echo -e "PING NOK"
fi

Он отлично работает, если проверка связи прошла успешно или вы запускаете команду вне сценария, но выдает приведенный ниже вывод, если нет ответа.

PING 1.2.3.4 (1.2.3.4): 56 data bytes

--- 1.2.3.4 ping statistics ---
1 packets transmitted, 0 packets received, 100.0% packet loss
PING NOK

Я видел ответы на этот вопрос, цитирующие 2>/dev/null, но тогда в выводе отображается весь запрос ping, независимо от того, успешен он или нет! Пример с 2>/dev/null, как показано ниже.

PING 1.2.3.4 (1.2.3.4): 56 data bytes

--- 1.2.3.4 ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 26.134/26.134/26.134/0.000 ms
PING OK

Это немного n00b вопрос, но я сетевик, а не разработчик :)

Заранее спасибо!!


bash shell if-statement ping dev-null
person Liam Mulligan    schedule 03.07.2017    source источник

Ответы (2)


arrow_upward
4
arrow_downward

«Классическое» решение:

if ping -q -c 1 -W 1 1.2.3.4 >/dev/null 2>&1; then
  echo -e "PING OK"
else
  echo -e "PING NOK"
fi

Несколько более современный (и не POSIX-совместимый!) подход, доступный начиная с BASH 4:

if ping -q -c 1 -W 1 1.2.3.4 &>/dev/null; then
  echo -e "PING OK"
else
  echo -e "PING NOK"
fi

Оба они означают «перенаправлять как STDOUT, так и STDERR в /dev/null», но первый делает это последовательно, сначала перенаправляя STDOUT, а затем перенаправляя STDERR в STDOUT.

person hidefromkgb    schedule 03.07.2017
comment
Идеальный! Спасибо большое. - person Liam Mulligan; 03.07.2017
comment
@LiamMulligan, с удовольствием. Не забудьте отметить вопрос как решенный. - person hidefromkgb; 03.07.2017
comment
Использование &> не более современно. Это ужасный хак, который нарушает стандарт оболочки (или в лучшем случае использует двусмысленность стандарта). Оболочка, совместимая с posix, будет интерпретировать cmd &> /dev/null так же, как cmd & > /dev/null, выполняя cmd асинхронно, а затем выполняя тривиальное перенаправление на /dev/null. Это конструкция, которую лучше избегать. - person William Pursell; 03.07.2017
comment
@WilliamPursell, разве не ясно, где интерпретировать &> как отдельный литерал, а где нет? То же самое происходит и с присваиваниями: variable=0 присваивает 0 $variable, а variable = 0 выполняет команду или функцию с именем variable, передавая = в качестве первого параметра и 0 в качестве второго. - person hidefromkgb; 03.07.2017
comment
Согласно стандарту, pubs.opengroup.org/onlinepubs/9699919799/utilities / , пункт 6 распознавания токенов, строка &> должна интерпретироваться как 2 токена. Можно утверждать, что пункт 2 заменяет пункт 6, но только если вы разрешаете &> в качестве оператора... но стандарт не распознает &> в качестве оператора, поэтому анализ ввода таким образом противоречит стандарту. - person William Pursell; 03.07.2017
comment
@WilliamPursell понял. Отредактировал мой ответ. - person hidefromkgb; 03.07.2017

arrow_upward
0
arrow_downward

Вы можете использовать статус выхода [ Проверьте это ] тоже..

ping -q -c 1 -W 1 1.2.3.4 >/dev/null 2>&1
[ $? -eq 0 ] && echo "Ping OK" || echo "Ping NOK"
person sjsam    schedule 03.07.2017