Re: BUG or OPERATOR error? - was [Re: Measuring aggregate internet useage?]
- To: email@example.com
- Subject: Re: BUG or OPERATOR error? - was [Re: Measuring aggregate internet useage?]
- From: David Wright <firstname.lastname@example.org>
- Date: Mon, 1 May 2017 13:31:07 -0500
- Message-id: <[🔎] 20170501183107.GC14026@alum>
- Reply-to: email@example.com
- In-reply-to: <firstname.lastname@example.org>
- References: <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <20170426123544.GH20910@eeg.ccf.org> <firstname.lastname@example.org> <email@example.com>
On Wed 26 Apr 2017 at 09:36:36 (-0500), Richard Owlett wrote:
> On 04/26/2017 07:50 AM, Darac Marjal wrote:
> >On Wed, Apr 26, 2017 at 08:35:44AM -0400, Greg Wooledge wrote:
> >>On Wed, Apr 26, 2017 at 01:25:18PM +0100, Darac Marjal wrote:
> >>>For interface statistics from ip, try "ip -s link [interface]".
> >>On stretch:
> >>wooledg:~$ ip -s link eth0
> >>Command "eth0" is unknown, try "ip link help".
> >>wooledg:~$ ip -s link dev eth0
> >>Command "dev" is unknown, try "ip link help".
> >>wooledg:~$ ip link help
> >>[... enormous BNF dump, entirely missing -s, or any reference whatsoever
> >> to the fact that you can stick options between "ip" and "link" ...]
> >>wooledg:~$ ip -s link show eth0
> >>2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
> >>state UP mode DEFAULT group default qlen 1000
> >> link/ether a0:8c:fd:c3:89:e0 brd ff:ff:ff:ff:ff:ff
> >> RX: bytes packets errors dropped overrun mcast
> >> 380719013 1442490 0 0 0 4731
> >> TX: bytes packets errors dropped carrier collsns
> >> 57971257 614586 0 0 0 0
> >My bad. I actually only got as far as discovering "ip -s link" on my own
> >system. As I was typing up the email I remembered that Richard was after
> >statistics for a specific interface. I should have been more diligent in
> >working out the correct format.
> >>(Sadly, this is my *typical* experience with the ip command -- trying
> >>random things until one of them works, because the documentation
> >>is impenetrable, and the syntax barely guessable, and certainly not
> >ip *could* do a lot better, it's true. As a monolithic tool, there's not
> >really much excuse for the different sub-tools to parse the commands
> >differently. As you say, "ip address" expects the device to be expressed
> >as "dev eth0", so why doesn't "ip link" handle it the same way? I don't
> I would go further saying iproute2 is non-functional due to being
> functionally un-documented.
> https://manpages.debian.org/jessie/iproute2/ip.8.en.html is useless.
It is if you want to know exactly what you can do with one of
the seventeen different objects it can handle. If you want to
know what those objects are, or what options are available, it's
> Functional commands, for this thread's topic would be
> ip -s link
> ip -s link ls usb0
> No hint of either in so-called man page.
> I accidentally discovered it by following up links when doing
> DuckDuckGo search for "documentation iproute2" (w/o quotes).
> I then did another netinst of testing. There is some subset of the
> "ip" command available after the network has been configured. The
> help is too abbreviated to be useful.
Not at all. The abbreviated help shows you what's available
during the installation process which, as you have noticed,
is often a subset.
Having ascertained that subset, you now know which parts of the
main documentation, available in various locations, still apply.
You seem to want the cut-down man pages to be included in the
installation, which is a surprise coming from someone who seems
concerned about bandwidth almost to the point of obsession.