> ifconfig's output is simply more readable IMO

Yes, this is key, and why ip is so terrible for the way I currently work. No doubt I'll have to get used to it, like those stupid biosdevname interfaces.

90% of my machines don't have more than 1 IP per physical interface, the rest are aliases

ifconfig outputs clear whitespace, so picking out the specific details of

- interface name

- ip address

Is far easier. I do prefer /28 to 255.255.255.240 when specifying subnets, but it does make it far harder to scan what the IP is. I suspect the people writing the utilities are the ones who are able to automate everything, as they do the same job 1000 times, with IP in, IP out, and no concern about physical devices, so rarely use the tool to read data, certainly not as a human.

You've then got the "what's the default gateway" problem

route -n

shows it nice and easy

  Kernel IP routing table
  Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
  0.0.0.0         172.26.32.1     0.0.0.0         UG    0      0        0 eth0
  172.26.32.0     0.0.0.0         255.255.240.0   U     0      0        0 eth0

ip route -n returns

  ip route -n
  Command "-n" is unknown, try "ip route help".

Helpful, ip route help is no help at all

It's all good having tools to manage lots of ip namespaces etc, that's great in the subset of cases you need that functionality, but for those of us that manage physical machines with physical inputs/outputs, rather than datacenter scale devices, it's a right pain.

to get the gateway: ip route show default

> > ifconfig's output is simply more readable IMO

I prefer iproute2's terseness.

I'm not sure "terse" is the right adjective. It presents basically the same amount of information as ifconfig (minus the packet counters) and actually adds a few more flags. It's all about the formatting really. Simply adding an empty line between each interface would go a long way. Also starting the line with the interface name instead of the index.

Adding more punctuation to delimit the fields (, : etc...) would be nice too. I mean what the hell:

    mtu 1500 qdisc pfifo_fast qlen 1000

It sounds a little bit like air traffic control: "roger dev gbe zero niner alpha one you are cleared for proto kernel scope link strip 4 dash 7 F L 11400 gamma zulu src please copy."

Huh, does "ip" also support "tc" (traffic control) commands - qdisc is a queueing discipline... tc seems to be the an earlier thing from the people who brought us ip. tc must have the worst command line interface and documentation ever - it is very hard and very frustrating to use, like no other command line interface I've ever seen.

I once tried to use tc and gave up after more than a day of trying, that is how bad it is. The syntax is a word soup and the semantics are very poorly explained.

ip/ss/tc are all netfilter based things all in the iproute2 repo.

http://inai.de/images/nf-packet-flow.png

tc is implemented by packet pacing at either egress or ingress steps.

and this is how iproute2 compares to the old net-tools stuff: https://linoxide.com/wp-content/uploads/2014/05/Linux-Nettoo...

netfilter: https://en.wikipedia.org/wiki/Netfilter#/media/File:Netfilte...

regarding UI/UX/CLI. yes, there's no arguing about it, it's just horrible. no documentation, no discoverability, no sanity. but it works, and it's free :o

MegaCLI (lsi hw raid control) sees your tc and raised you a few million awful flags.

After working with it almost daily for years I'm finally fluent in MegaCLI. I can even understand the --help for the most part. Time to get a new job I guess.

Nah.. Just time to relearn it all with StorCLI instead.

:-(

I see your MegaCLI and raise you certutil: https://docs.microsoft.com/en-us/windows-server/administrati...

Oh fair enough but in the context of Linux command lines I think MegaCLI is genuinely one of the worst UX designs ever. Up until recently (post Balmer), Microsoft didn’t heavily emphasize the CLI for most things so a bad UX is not surprising.

I'm pretty sure MegaCLI was written by someone who used to write software for digital phone switches.

Ah, my old friend MegaCLI. Simultaneously the most verbose and the most useless --help output I've ever seen from a command-line program.

I spent a bit too long on playing with tc a while ago. The best I could get it was to limit each person's download speeds from the one internet connection we had.

I'm with you on tc having the worst interface and documentation that I have seen from a command before. I spent maybe a few days total on it then gave up because I figured if there isn't much documentation on it, it isn't worth figuring out.

I used tc for something interesting once: I setup Cassandra nodes in distinct docker containers running on a single laptop. I installed tc in each container to throttle packets flowing between containers and in so doing, simulated a lossy, high latency WAN network. The goal was to evaluate how Cassandra fared as network latencies increased.

tc fit the bill nicely.

Did you remember to disable your swap file/partition?

https://stackoverflow.com/questions/22988824/why-swap-needs-...

So glad I'm not the only one with the same criticisms

I think the problem is, that these tools lack the extended human friendly output. They work well for those who use them regularly, but there's no `ip --explain`. Alas Linux and the kernel is famous for having very barebones or bloated and useless documentation.

I can take "mtu 1500" part, and sort-of "qdisc", but what's up with repeating obscure parameters at their default values, for each and IP address:

  valid_lft forever preferred_lft forever

Those are lifetimes for default (outgoing) address selection.

RFC 3484 "Default Address Selection for Internet Protocol version 6 (IPv6)".

That just shows its user-unfriendliness further. Here's a more readable version of the output:

> ip route | column -t

(With iproute2 4.3.0, I get the same output between "route", "route show", and "route show default"; no idea if it's changed since.)

Wow. That's actually kind of a tiny little brilliant gem that remains to be discovered by many. I, for one, had never though about trying this.

Alas it doesn't work quite so well for "ip addr". It would have been great if they'd just decided on CSV or JSON or whatever and then relied on secondary utilities to go to "pretty-printed".

Somewhere else in here, someone else mentioned that "ip" has "--oneline", which does seem to work decently, at least for the first couple columns:

   ip --oneline addr | column -t

When asking "what's the default gateway?", more often than not, the real question you have is "what's the gateway to IP address X", which would be:

  ip route get X

No it's not, it's usually "What is the default gateway on this network segment because I want to plug my laptop in"

I do use ip route a fair bit - if I have a machine connected to two (or more) network segments and want to ensure traffic gets routed back the way it came

However my main criticism for "ip route" is that it's inconsistent and a change route "route"

"route" does reverse dns lookups - e.g "my.server.tld rather than "1.2.3.4", or "default" rather than "0.0.0.0"

"route -n" shows 1.2.3.4

"ip route" doesn't do reverse lookup, however it does say "default" rather than "0.0.0.0".

Then reask: whats the gateway to 0.0.0.0/0

> "ip" is useless as a keyword

Most docs will mention iproute2. You can use that for googling.

On my CentOS 7 system, there is no iproute2 package, but there is an iproute package. Neither 'man iproute' nor 'man iproute2' produce any man pages. The iproute package provides the contents of /etc/iproute2, among other things, so why is the package name just iproute? The man page for ip has the name iproute2 at the very bottom, where it is easily missed. It would never have occurred to me to look for either iproute or iproute2 for information on ip had I not come across this posting. A little consistency of naming, with better cross referencing, would sure be nice...

What you're describing seems like an inexcusable state of affairs, but as a practical matter `man -k <search term>` or `apropos <search term>` is useful for finding poorly named manpages.

Of course in the specific case of "ip", both are going to return quite a haystack to search through...

Yeah that’s what I loved about this article, I finally know what to google.

Future tip: your package manager should be able to find this for you, for example:

> $ which ip

> /sbin/ip

> $ dpkg -S /sbin/ip

> iproute2: /sbin/ip

You may also want 'whereis' instead of 'which'.

I use cope to colorize my output, which makes 'which' useless to me for most common commands, but 'whereis' still works.

Edit for examples:

    $ which ip
    /usr/share/perl5/vendor_perl/auto/share/dist/Cope/ip
    $ whereis ip
    ip: /usr/bin/ip /usr/share/perl5/vendor_perl/auto/share/dist/Cope/ip /usr/share/man/man7/ip.7.gz /usr/share/man/man8/ip.8.gz

In bash, there's also:

    command -V

Which knows about aliases and functions as well:

    $ command -V ip
    ip is /sbin/ip
    $ command -V ll
    ll is aliased to `ls -AlF --color=auto'
    $ command -V command_not_found_handle
    command_not_found_handle is a function
    command_not_found_handle ()
    {
        if [ -x /usr/lib/command-not-found ]; then
            /usr/lib/command-not-found -- "$1";
            return $?;
        else
            if [ -x /usr/share/command-not-found/command-not-found ]; then
                /usr/share/command-not-found/command-not-found -- "$1";
                return $?;
            else
                printf "%s: command not found\n" "$1" 1>&2;
                return 127;
            fi;
        fi
    }

> whereis

Thanks for this! After 14+ years of using Linux almost daily, I had never heard of this command. I learned something new today, so now it's time to go home!

Yeah, I recently "discovered" the commands 'whatis' [0] and 'apropos' [1] and my experience learning Linux improved quite a bit.

[0] https://linux.die.net/man/1/whatis

[1] https://linux.die.net/man/1/apropos

Thanks for passing those on as well!

I finally found out how to get netstat on these dang new systemd machines! :)

That's a good tip, thanks.

That being said while docs specifically written about the tool will probably mention it random forum posts, tutorials or even stackoverflow questions may not.

> "ip" is useless as a keyword if you're looking for help online.

I don't know the decisions behind the naming either, but the ip shell command comes as part of the iproute2 [1] package.

After I found out about this googling became much easier.

[1] https://en.wikipedia.org/wiki/Iproute2

Well, sure, but assume you're new and you don't know that. You can usually search for "man ip" to get close, but that usually just gets you a technical reference for an experienced user (the man page) and not a tutorial, introduction, or training doc for someone learning a new tool. "ip command tutorial" works well, though the results are still rather mixed. I get Cisco and Windows results as well until I search "ip command tutorial linux".

The point is that searching for "ifconfig tutorial" is going to give you what you want, while "ip route" is probably going to get you Cisco documentation, honestly. Even something like "parse ip output" is going to give you a mix of results from Linux, Windows, or web services while "parse ifconfig output" is a lot more clear.

"ip" is simply a saturated keyword, making it a bad keyword.

Not sure why you think I would disagree. I'd say that is exactly my opinion, so I wanted to share that googlable term with the other frustated people out there.

I don't think you'd disagree. I just think, "Well, you could search for iproute2," isn't that helpful because it's not that obvious that that is the package name.

Exactly. Even the `ip` name is misleading as the command does much more than only ip-related things (link layer, network namespaces, tcp, …).

Always wondered about this - is IP 'internet protocol' or something else, since it's much lower level than IP? I've been using IP route 15 for 15, maybe 20 years now and hinestly have no idea.

Yes, it is 'internet protocol' [0] and part of TCP/IP.[1]

[0] https://en.wikipedia.org/wiki/Internet_Protocol

[1] https://en.wikipedia.org/wiki/Internet_protocol_suite

I know what IP is. Your reference doesn't answer the question as to whether 'ip' means IP.

Poking at ip and its sub-commands reminds me of poking at the serial interface of a Cisco router, and not in any pleasant way...

The man page is good.

`ip` takes a --oneline arg to make it more parseable.

I'm not sure having everything crammed into a single line makes it better (at least if a human is supposed to parse it and not a machine): https://svkt.org/~simias/up/20180525-125636_ip-vs-ifconfig-2...

I have used ip -oneline to parse configuration of servers, and it's really practical.

The only real gripe I have with IP is their long argument/switch format. Unlike everyone else, ip is a minority, which accepts long options with single dash "-". This prevents someone from combining many short parameters under a single dash, also it's confusing to use.

Yes, it unofficially supports the old double dash format, but if you are supporting it, there's no point in supporting single dash long options.

This is ridiculous. I would love to know their justification for using single dash for long options. When did that become the "old way"?? Very old X11 commands and many Solaris commands use a single dash, but nearly all modern commands use double dash. And I agree that this syntax makes it hard to combine single-character options. They must have had a very compelling reason to use a non-standard option syntax.

The Golang flag [0] package uses a single dash for long options.

The flags that a UNIX command uses can sometimes used to carbon-date that command. For example, dd(1) doesn't use a dash at all, uses long args, and uses an equals-sign to connect a flag with its argument (e.g. `dd if=/dev/null`). It's because dd(1) was written in the dawn of UNIX, before a convention was established for flags.

I believe the first step in creating a convention was the introduction of the getopt(3) library, which introduced single dash, single character options (e.g. `tar -x`). Commands that only have short options tend to be old commands.

Later, GNU introduced getopt_long(3), which allowed for long options and double-dashes to distinguish them from the short ones. This made commands more readable.

There have also been cases where the `-` is optional. `tar xvf` for example. And with the `ps` command, the `-` is used to distinguish BSD flags from System V flags (e.g. `ps auxwww` vs. `ps -elf`).

There has also been a movement for subcommands rather than options (which bring to mind the Cisco CLI), of which `ip` is an excellent example: `ip route show`. But subcommands are not a substitute for options; sometimes you need both (e.g. `ip -6 route show`).

All this goes to show that, although long options are quite common, they are not only game in town, and UNIX commands have a rich and varied set of conventions.

[0] https://golang.org/pkg/flag/

The dd syntax is meant to mirror that of the IBM JCL command dd, and it may have been meant as a joke.

Old versions of sort used a + to begin some options. So yes, there has been a lot of variation over time, but I see no reason to gratuitously diverge from the common standards now in use, unless following them is too restrictive in some way.

Re: Go, it describes the flags with a single dash, but it will accept them with a double dash and a more traditional style (both --string "foo" and -string="foo" are accepted, for instance)

Accepting everything at the same time is very nice in theory, but in the optimal case, the library should be able to mimic at least some established conventions.

Extreme flexibility becomes a burden after a certain point if it lacks adaptability.

Standards are built for these reasons.

For tar, x,t,c are commands not options.

For the `find` command the single dash is for predicates not for options (not that it makes a whole lot of difference)

There's an old school of programmers who resist double dash for long opts. Partly for historical reasons.

You'll find them in ex-Bell labs people (e.g. go-lang) and associated (docker).

The double dash was born in the 90s; there was a poll on Usenet gnu.misc (or similar). Those who did not habituate usenet didn't get the memo.

openssl uses single dash for long options too: -inform, -outform, -text, -noout, etc.

gcc uses single dash for long options too: -std, -pedantic, -dumpspecs, etc.

I am sure there are many more modern commands that do this.

As most applications older than a year are called legacy nowadays gcc (~30 YO) or openssl (~20 YO) are not what comes into my mind when asked for "modern" commands.

Neither are for 'dd' or 'tar' (probably 30 YO) from the other comment.

There are probably other, younger commands not following the --long-option pattern, but i think that doesn't make it better to break this convention.

The only other place I've seen single-dash long options be the norm is within TCL scripts (where that's conventional whenever a proc takes named arguments/options).

A --json arg would be much more parseable. I wonder if they'd be against that?

They won't. In fact it is already implemented. Try `ip -json addr`.

Not all subcommands support it though.

There's another universe near ours where libxo caught on widely, and every command supports text and JSON output out of the box:

https://juniper.github.io/libxo/libxo-manual.html

Which version has implemented this? It's not available here.

  rascul@coyote:~$ ip -json addr
  Option "-json" is unknown, try "ip -help".
  rascul@coyote:~$ ip -V
  ip utility, iproute2-ss160111

Looks like it was added in August of last year. Obviously newer than what my distribution has.

https://git.kernel.org/pub/scm/network/iproute2/iproute2.git...

NIH doesn't seem to make sense as "next of hop" or "not in here", and search for this initialism is obfuscated by the National Institute of Health.

Mind expanding NIH?

Not Invented Here (https://en.wikipedia.org/wiki/Not_invented_here)

Better to avoid vague grammars when not everyone is a native English speaker.

Pretty discoverable/common: https://www.urbandictionary.com/define.php?term=NIH

I think google is smart enough that you search with "ip command" (maybe plus "linux", it'll get relevant results.

It's better that the command you type often is short, (you can certainly alias ifconfig as "ifg" or anything too).

Maybe you're better at googling than I am but I've had serious issues with that. The problem is that there are way too many false positives for any query containing "ip" regarding networking. And even looking at the excerpts on the search results page it's not always obvious if "ip" refers to the command or something else.

Take for instance a very simple query: "ip show default route":

https://duckduckgo.com/?q=ip+command+show+default+route&t=ff...

There are a few obviously relevant matches in the first page but also a bunch of completely irrelevant results. Adding "command" doesn't improve that much. And that's for a very simple query that's probably been asked hundreds of times before.

Meanwhile if I search "ls sort date" I get mostly relevant results immediately because even though it's also a 2 letter identifier it's not quite as ambiguous: https://duckduckgo.com/?q=ls+sort+date&t=ffab&ia=qa

Yes, DDG gets relevant results too: https://ddg.gg/?q="ip+command"

Bookmark this PDF: http://homepage.smc.edu/morgan_david/cs70/ip-cref.pdf

Yeah, that's if you even have "ip" Was using one of Redhat's base image the other day and there was no "ip" installed, we tried all the tricks in the book searching through /proc to find the ipv4 for a new interface, and we couldn't, we could easily grab the ipv6. Ended up writing some code to grab it using python. :-/

If only ifconfig was standardized on the output... it's output has changed over time

Let alone the non-conformity of other OS's like Solaris, HP-UX which really might not matter now. I'm sure FreeBSD matters to someone... just not me

It could also be preserved as a legacy flag.

  ifconfig -L

(I don't know if this is already taken. I haven't read the man pages in forever.)

I love how much shorter and terse the output is with iproute2. I reach for it a lot on my mac and get a bit sad when it’s not there.

I've always thought the same thing. ip addr's output sucks compared to ifconfig.

Looking at it more closely now, ip addr's output doesn't seem that difficult to fix. Remove that random number before the adapter name (what the hell is that anyway? The order in which the adapter appeared? If so, why are not in that order?)

I think that alone would make it so much more readable! Maybe white space between each entry with a flag?

All of the help sections are awful too. I feel like I'm looking at language grammar definition instead of useful usage information.

It’s the interface index which is mostly an incrmsenfing number. That can become important for sub interfaces and others things that may reference it. Though they could reference by name instead.

If you like India Pale Ale, then the handy "ip a" command might come second nature to you. Sounds weird, but this mnemonic was what I needed to get on board.