all of the lines that aren't part of the query answer are prefixed with semicolons. so it's basically a comment character. presumably to ease processing of the data it spits out.

You know. So you can `dig google.com | grep -v '^;' | grep . | awk '{ print $5 }'` easily.

I can imagine people using it in a shell script 20 years and more ago to grab a list of IPs to do some domain's health check or whatever

Not that you would want to in any modern stack. obviously you'd just use dig's `+short` option :)

I already know to use +short when I just want the result(s). I use it in a script to detect and resolve my Pihole's random freezes (by timing the lookup and rebooting the VM every time a lookup fails or takes longer than 200ms, janky but it works).

It wasn't really your point, but hopefully you'll forgive me sharing an equivalent one-liner, without grep:

dig google.com | awk '/./ && !/^;/ {print $5}'

     dig example.com | awk '/\./ && !/^;/ {print $5}'

If matching everything was intended then you don't need it at all:

     dig example.com | awk '!/^;/ {print $5}'

However, parsing the output of `dig` this way is not needed. It can be ran to only return the answer, for example:

     dig +noall +answer example.com

     dig +short example.com

I could have combined `grep -v '^;'` and `grep .` as a nice simple `grep '^[^;]'`

However, it's still better to just have the `dig` command return only the necessary information via the +short or +noall +answer flags, rather than parsing the full output.

    The labels must follow the rules for ARPANET host names.  They must
    start with a letter, end with a letter or digit, and have as interior
    characters only letters, digits, and hyphen.  There are also some
    restrictions on the length.  Labels must be 63 characters or less.

it's more likely that in the late 90s they just made up their own argument parsing that they liked and the application has just used that ever since.

I’ve never considered DNS to be a complicated technology, and I’ve never considered that tools like dig and the abbreviations they use need to change much. If there’s something that isn’t clear, it’ll be in the man page, a mailing list, Internet based documentation, StackOverflow, etc.

Personally, I value information density, and I don’t mind terseness at all.

That doesn’t necessarily mean I would design some of this stuff the same way, but after more than a decade using it, I feel like changing it now is just an appeal to futility. A tool like dig more or less looks and works the same today as it did 15 years ago, and there’s value in that kind of stability.

And that's why your learning to use these tools a decade ago was as painful as it was for me 20+ years ago, and so on. Nobody improves it because the only people with the clout to make the changes is too set in their ways to change it, and have come to believe the ridiculous notion that it's beneficial for people to learn it, despite not being related to the actual problem.

I worked in technical roles for the better part of 25 years, including 10 as a back end developer. One of the reasons I got into design was to try and break chains like this, but talking to the FOSS community about design gets nearly zero traction and a whole lot of pushback from folks who think they know a lot more about design than they do. Nothing you do matches the information density of a train schedule in a large city, and those designs are so ubiquitous and intuitive that we take them for granted. That was not always the case— someone decided to lay things out like that at some point because they knew it works be easier and more intuitive for the majority even if it might take some adjustment for existing everyday users. And designers still work to make them better, to this day.

I wrote a tutorial teaching non-technical folks to use a rest API. It required no knowledge beyond familiarity with using web browsers, and ended with people making useful queries with curl. It was short, visual, and effective- I learned that multiple non-profits at the time used it in their materials to teach folks technical literacy. Just because using a bunch of terse jargon is easier for developers to write and acceptable for other developers to read doesn't mean it's optimal... Or even good. Especially when the realm world be much more accessible to non-technical people if it was designed better.

The CLI is inherently a super-user oriented interface. The CLI needs to let an experienced user be as productive as possible.

If you need a pretty UI with everything spelled out, you should go on GitHub and find a GUI that someone built on top of the core tool. But dumbing down the core tool is not the way to go.

The --help message should be good, and the man page needs to be good, but the tool itself should favor power and productivity over handholding someone who doesn't want to Google a how-to.

Old-school FOSS nerds have a hard time admitting that they tend to be absolutely useless at considering user experience, because then that’s something On Computers that they’re not good at. The best they can do is shoo it away by claiming that the sort of UX concerns I’m talking about only apply to software used by Lesser Beings and not Smart Computer Boys such as themselves.

It’s such an outdated user-hostile boys club attitude fuelled by insecurity and misplaced and not even well-thought-out elitism, and I’ll never pull any punches when talking about it.

Yes it is. As an administrator being a CLI tool means that I can automate configs and deployment with ansible or Nix OS. I would argue doing these sorts of automation what are what “power-users” would do.

GUI’s often lack any sort of automation capability or have some half-cocked API that usually lacks features or endpoints that would be trivial if the thing was just a CLI tool with a config file.

Using sane labels and coherent layouts isn't dumbing anything down. You can make things easier for humans while having sane interfaces for scripting. Redirecting the output of `ls` and similar commands automatically change the layout to something easy for cli i/o manipulation.

We realized long long ago that the API and human-facing interfaces are often better when separated, which is why I don't browse the web with curl... or maybe telnet.

New-school FOSS nerds don't seem to understand that all poor user experience concerns are because we are trying to be productive. The new style of of reduced information density and easy-to-remember names isn't useful when you are paid to have production systems up and running. What I need are tools that give me the exact information I need quickly and get the fuck out of my way for everything else.

> It’s such an outdated user-hostile boys club attitude fuelled by insecurity and misplaced and not even well-thought-out elitism, and I’ll never pull any punches when talking about it.

Most people that complain about this put the minimal viable effort into actually learning what they are doing. Somehow I'm the idiot after spending hours of my life to learn this professionally and for wanting expert interfaces. You can call me elite all you like but when the whirlpool of disaster is pulling us both under, I'll be in my elite raft surfing the waves while you struggle.

> New-school FOSS nerds don't seem to understand that all poor user experience concerns are because we are trying to be productive. The new style of of reduced information density and easy-to-remember names isn't useful when you are paid to have production systems up and running.

The reason you find them more productive is because you already know how to use them. Needlessly reduced information density is usually a bandaid applied to a shitty, confusing interface by a non-designer because they don't know how to organize it to be easily parsable, but still dense. Maybe denser than before. You don't even realize when a good designer has done a good job because it just makes sense— it's so intuitive and useful to cite users that you don't have to think about it. If it it's a utilitarian tool that "looks designed," it was probably a non-designer trying to gussy it up, or "work on UX" without realizing that means a lot more than white space, colors, and fonts. A solid understanding of visual hierarchy would solve at list half of FOSS interface problems without changing anything other than layout. The problem is project maintainers who think any attempt to remediate their non-designed cobbled-together interface is an attack by the 'new school' or what have you and either dismiss it out of hand, or reflexively bikeshed any proposal into oblivion because they're defensive, and lack the design sophistication to knowledgeably engage. As a senior developer and someone who enrolled in art school as an adult, I know how much more defensive people get about work they're not confident in. When those people are in charge of a project AND have the misguided notion that their "design" (read as cobbled-together assembly of user-facing functionality) is more functional than an expert's design, just uglier, good luck pushing change through.

> Most people that complain about this put the minimal viable effort into actually learning what they are doing. Somehow I'm the idiot after spending hours of my life to learn this professionally and for wanting expert interfaces. You can call me elite all you like but when the whirlpool of disaster is pulling us both under, I'll be in my elite raft surfing the waves while you struggle.

And fraternities keep paddling pledges and making them drink gallons of grain alcohol because they all had to do it too, so everybody else should. Complaining that nobody wants to spend time studying something that they wouldn't have to if it was properly designed is an asinine argument against progress. The only people here who should be chastised for refusing to learn new things are the people who refuse to consider better approaches and insist everybody else learn the same inscrutable incantations they did, because it's easier for them... Because they already know them. Just because you can't imagine productive ways to update these tools to a post-teletype world doesn't mean that nobody can.

If you have trouble with tools like dig, you have wasted a lot of fucking time.

Measuring usability by your own comfort level is the reason user-facing "open source alternatives" that aren't foundation-backed with dedicated designers will remain "alternative" in perpetuity.

I'm a super-user and as such I have to use hundreds of tools to GTD. What you call “pretty UI” I call ergonomics. So I appreciate when the tooling is respectful of my time and don’t require me to visit the man page just because the developer was so situational myopic that thought sparing a few characters was a good idea.

It all smells like unconscious gatekeeping.

RTFM is usually (not always) a way to gatekeep bad UX.

For instance, you look at the dash of your car every time you drive, and what little is labeled is abbreviated. The expectation is that when you understand how the vehicle operates, the gauges and lights will make sense. The information is encoded behind your knowledge. dig isn't really different.

Some people want the tools to teach them everything, but that's just not appropriate or necessary, whether you're talking about a hammer, a firearm, or a computer.

> Once you're past that hurdle, it's redundant.

Yeah, then multiply that hurdle times the thousand others someone has to memorize to work in *nix.

> Some people want the tools to teach them everything, but that's just not appropriate or necessary, whether you're talking about a hammer, a firearm, or a computer.

Textual output on a computer is a communication medium-- hammers and firearms are not.

dig output make sense after reading the RFC. It exposes every bit flag in the protocol level

It's not as if tools like wget bother you with http/3 spec fields every time you download something from the internet unless you explicitly ask for them, and even if they do, they're more descriptive than just the shortcode coming from a diagram in the RFC.

That's the root of all this, we only deal with DNS when something breaks, and it rarely breaks.

If we did DNS all day every day it'd all be super clear and concise.

I still tend to use nslookup over dig (yes, I know, bad mst) because I got sufficiently used to the former that I barely notice it's even there when using it - my fingers and brain are so used to it that the interface part of nslookup is mentally invisible (though I always teach other people 'dig' and 'host' instead).

I'm not sure learning it that way was exactly easier, but being (somewhat, that was far from the only service I was responsible for) immersed in it meant I at least got through the initial mental scrabbling in a relatively compressed time frame, and once you've got a coherent model built in your head life is easier.

I think this is really a very long way to say "based on doing DNS most days for a few years, I strongly suspect you're right."

But that's only like 10% of DNS's surface area, there's tons of other things it can do and rarely does, but if you have to make that stuff work you can get deep in the weeds fast.

are defined in the RFC. It need the abbreviation to fit in the ASCII art in RFC text.

back in those days, dig users are those who read rfc

dig already translates things like record types from integers to strings, why not use the full, descriptive names for these flags as well? Why shouldn't I be able to dig +pretty domain.example?

I suppose dig is mostly maintenance mode these days, but it's quite annoying to see so many tools rely on it when it's so... 90s.

Due to backwards compatibility, the output won't be changed. Due to backwards compatibility, stuff is the tool that's installed by default.

Both can't be changed (it would break too many assumptions many scripts and programs have).

However, there are multiple dig alternatives. You just have to install them.

https://github.com/ogham/dog is pretty good in that regard

  $ ip address --color
  Command "--color" is unknown, try "ip address help".

> ip --color address

otherwise you might just have an old version

    <command> <command options> <subcommand name> <subcommand options> <arguments>

The disadvantage is, well, what just happened to you.

(note that I personally really like the pedantic approach because it fits my brain, but I'm -not- trying to endorse it as better in general since it's very definitely a trade-off and one that often isn't a good one overall)