ping -O 192.168.x.x
When the remote ip is not alive, ping output error message
no answer yet for icmp_seq=1
no answer yet for icmp_seq=2
no answer yet for icmp_seq=3
But today I found on Leap 15.6, ping output error message to stdout instead of stderr.
I can remember about 2 years ago when I used ping it outputed error to stderr
What procedure are you using to prove output is going to stderr or stdout?
First I concur with @myswtest , please always post complete, starting with the prompt-command line, all output and best including the new prompt (so we can see it is complete).
Then, indeed we can not see if the output goes to stdout or stderr.
But, I do not think the output you show is an error message. You asked for it with the -O option, thus it is just the normal output you want to see and no error at all.
What procedure are you using to prove output is going to stderr or stdout?
$ ping -O 192.168.x.x 2>/dev/null
Above command redirect stderr to null. But I still see no answer yet for icmp_seq=X in terminal. A simple way to find out.
You asked for it with the -O option, thus it is just the normal output you want to see and no error at all.
-O tells ping to output no answer yet for icmp_seq=X every second if target ip not responding. I want to redirect responding log and non-responding log to different files.
2 years ago (can’t remember the Linux version), when I used -O , the no answer messages were sent to stderr by ping. I think that’s how ping designed.
This again is NOT a complete command/output posted. And obfuscating part of de command will not help in people understanding your problem. When I e.g. try to re-create your problem:
henk@boven:~> ping -O 192.168.x.x 2>/dev/null
henk@boven:~>
I get no output at all because the error is dumped.
henk@boven:~>ping -O 192.168.x.x
ping: 192.168.x.x: Name or service not known
henk@boven:~>
Does show the error. And mind that this is a real error message, contrary to your messages that aren’t.
That your memory tells you that it was different does not help very much. I find it logical that they are not errors, but the output asked for. So when you are correct that it once was different, I guess that they found out that it was bad design and they repaired it.
When you want to reverse this, you have to ask the developers (e.g. through a bug report), but I think your changes are minimal.
For (#1) I think there is a misunderstanding how “ping” works.
So, if you want to ping the literal address, “192.168.x.x” will always fail, and the ping command will stop executing immediately.
It outputs the error message to stderr, then stops. You will never see the “no answer yet for icmp_seq=xx” stdout messages.
For (#2) In order to see the “no answer yet for icmp_seq=xx” stdout messages, you have to use an IP address that may possibly be valid, such as “192.168.14.14” (or whatever else).
To be clear, ‘x’ is not a real number.
Then you would execute the ping command in this fashion - and you will need to use a possibly existing IP address, such as:
user@mach :~> ping -O 192.168.14.14 > stdout.txt 2> stderr.txt
( I waited about 4 seconds, then did a ^C to abort ping )
^C
user@mach :~> cat stdout.txt
PING 192.168.14.14 (192.168.14.14) 56(84) bytes of data.
no answer yet for icmp_seq=1
no answer yet for icmp_seq=2
no answer yet for icmp_seq=3
--- 192.168.14.14 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3049ms
user@mach :~> cat stderr.txt (empty because no errors output)
user@mach :~>
.
Now, let’s try using your test (using an invalid IP address):
user@mach :~> rm std*.txt
user@mach :~> ping -O 192.168.x.x > stdout.txt 2> stderr.txt
user@mach :~> cat stdout.txt (empty because there isn't any stdout)
user@mach :~> cat stderr.txt
ping: 192.168.x.x: Name or service not known
user@mach :~>
I know how to use command. I didn’t ping the literal address 192.168.x.x. I know we have to ping a valid IP.
When I post here, I replaced number with x, because we’re not in a same LAN so our LANs have different online and offline IPs.
What I was talking about is (assume 192.168.14.14 is not online in our LAN), when we run:
user@mach :~> ping -O 192.168.14.14 > stdout.txt 2> stderr.txt
( I waited about 4 seconds, then did a ^C to abort ping )
^C
user@mach :~> cat stdout.txt
PING 192.168.14.14 (192.168.14.14) 56(84) bytes of data.
no answer yet for icmp_seq=1
no answer yet for icmp_seq=2
no answer yet for icmp_seq=3
--- 192.168.14.14 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3049ms
I expect to see in stdout.txt:
PING 192.168.14.14 (192.168.14.14) 56(84) bytes of data.
--- 192.168.14.14 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3049ms
and expect to see in stderr.txt:
no answer yet for icmp_seq=1
no answer yet for icmp_seq=2
no answer yet for icmp_seq=3
You might remember that, but man ping does not specify where -O writes that output to, stdout or stderr; it’s simply undefined, so you shouldn’t rely on where it goes to.
man ping
...
...
-O
Report outstanding ICMP ECHO reply before sending next packet. This
is useful together with the timestamp -D to log output to a
diagnostic file and search for missing answers.
Well, reality is not according to your expectations.
And my expectations are different When I ask a program if something is blue, then I expect a yes or no and not an error detected when there is no error in the way I call the program.
As I have shown, error messages do go to stderr and thus go were redirection of stderr points to. The report you get is NOT an error. It is a report and a such goes to stdout
In this case you could go for the return code.
henk@boven:~> ping -c1 10.0.0.138
PING 10.0.0.138 (10.0.0.138) 56(84) bytes of data.
64 bytes from 10.0.0.138: icmp_seq=1 ttl=64 time=0.885 ms
--- 10.0.0.138 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.885/0.885/0.885/0.000 ms
henk@boven:~> echo $?
0
henk@boven:~> ping -c1 10.0.0.139
PING 10.0.0.139 (10.0.0.139) 56(84) bytes of data.
From 10.0.0.154 icmp_seq=1 Destination Host Unreachable
--- 10.0.0.139 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
henk@boven:~> echo $?
1
henk@boven:~>
So, yo could go for something like
henk@boven:~> if ping -c1 10.0.0.138 >/dev/null 2>&1 ; then echo OK; else echo notOK; fi
OK
henk@boven:~> if ping -c1 10.0.0.139 >/dev/null 2>&1 ; then echo OK; else echo notOK; fi
notOK
henk@boven:~>
BTW
I do not understand what you want to say with this, But not posting exactly what you did will lead to misunderstandings.
And when you think you have to change something because of security reason (like passwords), then always explain that. We take all posted CODE as literal.