[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Can we kill net-tools, please?



On 12/29/2016 08:38 PM, Russ Allbery wrote:
> It certainly doesn't provide a man page that doesn't start with a BNF
> syntax description.  The iproute2 documentation is awful.

Ack.

> Also, this is not at all easy to parse:
> 
> # ip -o address
> 1: lo    inet 127.0.0.1/8 scope host lo\       valid_lft forever preferred_lft forever
> 1: lo    inet6 ::1/128 scope host \       valid_lft forever preferred_lft forever
> 3: wlan0    inet 192.168.0.195/24 brd 192.168.0.255 scope global dynamic wlan0\       valid_lft 598191sec preferred_lft 598191sec
> 3: wlan0    inet6 fe80::a288:69ff:fe31:2b62/64 scope link \       valid_lft forever preferred_lft forever
> 
> The fields aren't labeled, you have to make a bunch of assumptions about
> ordering, the backslash thing is just completely bizarre and makes the
> parsing way harder (see the "lo\" on the first line)... this is really
> rather dire.

Ack.

> And the output (without -o) is less human-readable than the current
> ifconfig output, although neither of them are going to win any awards.
> ifconfig at least understands how to use whitespace to try to present
> data, which ip definitely does not, but both have a lot of cryptic
> abbreviations and provide a lot of uninteresting noise in the default
> output format that's only useful in unusual situations.

I personally hate both outputs as well, but vastly prefer ip over
the traditional ifconfig output. (The new ifconfig appears to have
gotten better, after just trying it for the first time.)

> ip address also has one of the worst output UI decisions I've ever seen,
> namely this line:
> 
>     inet 192.168.0.195/24 brd 192.168.0.255 scope global dynamic wlan0
> 
> specifically "192.168.0.195/24", which is notation (IIRC) invented by this
> command,

Nope, that's RFC 4632, Section 3.1, where that was introduced
first, see
https://tools.ietf.org/html/rfc4632#section-3.1

And at least I find it vastly superior to the traditional netmask
notation - if I see /29 I can immediately deduce that there are
three bits available for the host part, so with broadcast address
subtracted that gives me 6 hosts in that range. The corresponding
netmask is 255.255.255.248 - that is far harder to process
mentally for me. Add in IPv6 and there's a reason why traditional
netmasks have never been used there.

That said: to me it would have been much more logical to count
the bits that are zero in the netmask (as that defines the size
of the network directly) than the bits that are one, so I believe
there was room for improvement when that syntax was introduced.
Unfortunately that ship has now sailed...

Regards,
Christian


Reply to: