3

I'd like to omit the error from this IF statement if ICMP echo fails.

Example code:

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

It works perfectly if the ping is successful or you run the command outside of a script, but gives the below output if there is no response.

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

I've seen answers for this out there quoting 2>/dev/null, but this then displays the entire ping query in the output, whether successful or not! Example with 2>/dev/null as below.

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

This is a bit of a n00b question, but I'm a networking chap, not a developer :)

Thanks in advance!!

Liam Mulligan
  • 35
  • 1
  • 5

2 Answers2

5

The «classic» solution:

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

A somewhat more modern (and not POSIX-compliant!) approach, available since 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

Both of these mean «redirect both STDOUT and STDERR to /dev/null», but the first one does it sequentially, first redirecting STDOUT and then redirecting STDERR to STDOUT.

hidefromkgb
  • 5,834
  • 1
  • 13
  • 44
  • 2
    Perfect! Thanks so much. – Liam Mulligan Jul 03 '17 at 15:20
  • @LiamMulligan my pleasure. Don\`t forget to mark the question as resolved. – hidefromkgb Jul 03 '17 at 15:22
  • Using `&>` is not "more modern". It is a terrible hack that violates the shell standard, (or at best exploits an ambiguity in the standard). A posix compliant shell would interpret `cmd &> /dev/null` the same as `cmd & > /dev/null` executing cmd asynchronously and then performing a trivial redirect to /dev/null. It is a construct best avoided. – William Pursell Jul 03 '17 at 16:32
  • @WilliamPursell isn\`t it perfectly clear where to interpret `&>` as a single literal and where not to? The very same thing happens with assignments: `variable=0` assigns `0` to `$variable` while `variable = 0` executes the command or function named `variable`, passing `=` as the first parameter and `0` as the second. – hidefromkgb Jul 03 '17 at 16:37
  • According to the standard, http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_03 , item 6 of token recognition, the `&>` string should be interpreted as 2 tokens. Item 2 can be argued to supersede item 6, but only if you allow `&>` as an operator...but the standard doesn't recognize `&>` as an operator, so parsing the input that way is in conflict with the standard. – William Pursell Jul 03 '17 at 16:49
  • @WilliamPursell got it. Edited my answer. – hidefromkgb Jul 03 '17 at 16:51
0

You can use the exit status [ Check this ] too..

ping -q -c 1 -W 1 1.2.3.4 >/dev/null 2>&1
[ $? -eq 0 ] && echo "Ping OK" || echo "Ping NOK"
sjsam
  • 21,411
  • 5
  • 55
  • 102