Ping (shouldn't this be committed)?

In my review of other systems the printing of "default" for this is common and has a long history, changing it at this point in the game would probably be a POLA and possibly break some scripts. I have worked around the issue that caused me to notice this in another way.

We may want to change this into a man page fix that adds the fact that 0.0.0.0/0 is printed as "default" even with the -n option.

In D10320#239021, @rgrimes wrote:

In my review of other systems the printing of "default" for this is common and has a long history, changing it at this point in the game would probably be a POLA and possibly break some scripts. I have worked around the issue that caused me to notice this in another way.

We may want to change this into a man page fix that adds the fact that 0.0.0.0/0 is printed as "default" even with the -n option.

• Fedora Linux 22 does the conversion when -n isn't specified and doesn't do the conversion when it's specified.
• NetBSD 7.x has the same bug as FreeBSD.

I think for the sake of correctness we should do what this CR suggests and follow Linux's lead.

I still find this as a gratuitous difference in FreeBSD that does not exist in NetBSD or OpenBSD, and appears to be BSD behavior back into the 80's, anyone that HAS already scripted to deal with symbolic names well be broken if this change is made.

In D10320#295718, @rgrimes wrote:

I still find this as a gratuitous difference in FreeBSD that does not exist in NetBSD or OpenBSD, and appears to be BSD behavior back into the 80's, anyone that HAS already scripted to deal with symbolic names well be broken if this change is made.

Heh. I've been on the other side of this change and wished it were an actual CIDR format. There's demonstrable cost to being different and not breaking from the past.

Regardless, this is all the more the reason userland utilities with bespoke outputs should not be considered the API into the state of the kernel.

Thoughtfully...

There are three vantage points:

1. Backward compatibility

Keep "default" even with -n

2. POLA - Principle Of Least Astonishment

Arguable

3. Forward compatibility

For IPv4 you'd display "0.0.0.0/0" instead of "default"
For IPv6 you'd display "::/0" instead of "default"
There has been rumors of an IPv9 out of China.
Who's to say that "default" isn't the best choice because...
"default" means no change for the IP version.

I say that keeping "default" is arguably an approach that satisfies all three vantage points:

1. Backward compatibility
2. POLA
3. Forward compatibility

In D10320#239021, @rgrimes wrote:

In my review of other systems the printing of "default" for this is common and has a long history, changing it at this point in the game would probably be a POLA and possibly break some scripts. I have worked around the issue that caused me to notice this in another way.

We may want to change this into a man page fix that adds the fact that 0.0.0.0/0 is printed as "default" even with the -n option.

I am a fan of the man page fix approach.

However, the change that I would make to the manual is thus. Instead of:

Show network addresses and ports as numbers. Normally
netstat attempts to resolve addresses and ports, and dis-
play them symbolically.

Perhaps the following:

Don't attempt to resolve addresses (using name services)
and ports (using service(5)).

This not only explains what is prohibited by "-n" but how the resolution services are performed.

This also clarifies why default is not affected, because "default" is an alias to a common concept (0.0.0.0/0 for IPv4, ::/0 for IPv6, and something else for something future, e.g., IPv9), which is neither a name services translation nor a services(5) translation for a port.

I still believe this change should go in, although if we really believe it's a backwards compatibility issue perhaps avoid default only with -n -n or -nn?

Well, I am still on the fence with this one, seems someone has already done it to the route get -n command.

In D10320#351215, @emaste wrote:

I still believe this change should go in, although if we really believe it's a backwards compatibility issue perhaps avoid default only with -n -n or -nn?

-nn might be the right compromise. Although if route get has been changed already...

Should this change be committed?