Hacker News Reader

Comment by ljm | Hacker News Reader

Also, single dash for long args and not just short args. I think mostly Go tools do this, and whatever purism is used to justify the choice, I can't think of many CLI apps that don't use a single dash for short args (and combining a sequence of flags) and a double dash for long ones.

View on HN

Double dash for long args is a GNUism. One which even they don't adhere to uniformly as evidenced by GCC's options.

it's a simple to learn gnuism that most good tools follow but (mostly) java apps for whatever reason disrupted it and added a lot of mess.

The Java tools predate the GNU convention (or at best were developed at the same time, unbeknownst to each other). Golang uses single-dash as well (but also accepts double-dash), as do PowerShell and Unix commands like find. In early Unix, there wasn’t a clear convention to use a dash for options at all (dd, tar, ps).

GNU was established 10 years before Java.

GNU double-dash long options were devised only after POSIX disallowed using the plus sign in 1992: https://blog.djmnet.org/2019/08/02/why-do-long-options-start...

Java was already two years in development at that time.

It is, but combining a sequence of flags is POSIX.

`find` comes to mind. I consistently need to look up the syntax.

Use fd instead

In case people were curious: https://github.com/sharkdp/fd

If it’s not installed by default on server-oriented flavours of Linux then it’s dead to me, unfortunately. Most orgs aren’t going to agree to roll it out across tens of thousands of machines on a whim.

My entire Linux experience is dictated by what’s installed by default on rhel and/or ubuntu.

This is why I originally learned vi. Working on DoD machines as well as this of other consulting customers. I had a notebook of short scripts and commands that would make my life easier. I couldn't use any media or even reference the internet in many of the data centers and labs.

"installed by default" should never be a compelling consideration for an org with ten thousand machines, or one hundred. As soon as they have their own package repos and automatic deploy systems, it should be as simple as saying "fd is a fast file finding utility packaged upstream as 'fd-find'. Please add it to the deploy list for these classes of machines" or whatever else starts your change management system grinding.

Unfortunately that doesn't cut the mustard in most organisations either, with the typical responses being along the lines of: "Who will support it? Can you provide a security assessment? Is your team happy to be responsible for any issues?"

I sorely wish it was as simple as "please deploy", and in days of yesteryear you could probably get away with that either yourself or if you were friends with the linux team, but those days are over now as far as I see.

For context, my opinion comes from being a security consultant for over a decade - I see a lot of other people's environments and how their organisations handle requests like this. Not every environment will have objections, but most won't add it as a standard package across the fleet.

My opinion comes from decades of running the department that provides an initial security assessment and then signs up to support it.

Wonderful, thank you. I've already cut my typing in half with rg, I'm ready to commit to another 50%

It's most common in Go's own tooling (e.g. `go build -buildmode`) but is also present in older tooling like e.g. GNU findutils (e.g. `find . -name something`).

The go tooling also has the irritating tendency to take a command like `go build --help` and say "oh, run `go help build` for details" instead of just printing out a list of possible options. Also: the details page doesn't always present you with a list of possible options, so you have to read each paragraph to see if there's an option relevant to your interests.

A lot of Java tools do this for some reason and I hate it.

This sets me off. Whenever I have any viable alternative to a single dash long arg tool I take the alternative.

Personally, I dislike gnu style double dash and actively despise the double dash equals variant( --arg=value ). I just think it adds a lot of unnecessary noise to the command line.

And after a bit of shower thinking, you know that alone time with nothing better to do but ponder the mysteries of the universe, things like black holes, the nature of light and the ascetic of the command line. I decided that single dashes were also sort of ugly and hindered readability, but there was a better way as hinted by the single most screwball command in the standard unix installation.

Yes it is I ( evil laugh ), that misanthrope actively making new cli scripts what use dd style arg=value

http://nl1.outband.net/extra/remv.txt

Actually the real epiphany was when I was doing some work with "megacli" the tool for lsi hardware raid management. I noticed that sometimes I could forget to add a dash to an argument. A little experimentation showed that no arg actually required a dash and the capitalization was ignored. it was like a huge weight was lifted from my shoulders, much better this way.

    MegaCli -PdReplaceMissing -PhysDrv [1:1] -Array2 -row1 -a1

    MegaCli pdreplacemissing physdrv [1:1] array2 row1 a1

Does MegaCli still ship with its own copy of libc5 because it's so old and disgusting that they can't bring themselves to upgrade it? Or did they figure out how to resolve that eventually?

No idea. megacli was always a weird program you had to sort sneak on the server however you could fit it. it got renamed to cmdtool at some point(I think because intel were shipping lsi cards). Honestly I am fairly happy we no longer use hardware raid here. Too many mysteries.

> dd style arg=value

Likely inspired by JCL syntax!

https://en.wikipedia.org/wiki/Dd_(Unix)#History

Reply on news.ycombinator.com