Hacker News Reader

Comment by emmelaich | Hacker News Reader

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...

Reply on news.ycombinator.com