> I admit, my first thought on seeing the title was "What's wrong with xxd?"

My first thought too. Then I looked and saw it was nice, and then I noticed it's by sharkdp. He really has a knack for improving on things you thought were fine (fd and bat being other examples).

Looks like the screenshots on Github are outdated. I just ran it locally and it does print out offsets in a new left-most column.

edit: Added in this commit: https://github.com/sharkdp/hexyl/commit/91a119f4537f746045c8...

Since back in my DOS programming days, I've lived in several different Hex editors when analysing data streams. Some great, some ordinary. I would have killed for colour highlighting like Hexyl seems to have.

I wonder though, whether I can colour code 'blocks' to differentiate them? One of the things I seemed to do a lot in hex editors was to check out the differentiation in, for example, 72 byte blocks of data, so to be able to delineate 72 byte blocks in different colours in the hex editor would make it easier to see where each block starts/ends.

What are line numbers in context of a binary?

Right, I was being a bit loose there. I meant something like how `xxd` displays the number of bytes up to the current output row. Just something to give context of where you are in the file.

    00006980: 0000 0000 0000 0000 0000 0000 0000 0000

You can quickly find position of byte number X using:

line number = floor(X/(bytes/line)) + 1

column offset = X % (bytes/line) + 1

Or it could just print byte numbers instead of line numbers.

Addresses.

File offsets; not addresses :) I assume the tool isn't reading ELF format files and working out the memory address.

haha, had exactly the same thoughts. the colours really makes it much much easier on the eyes to recognise things. well done!

Same thought except, I wonder why this isn’t a patch to xxd?

I'm struggling to even find the canonical source code for xxd, let alone a way to provide a patch. You could probably email the address in the man page, but that's from 1997 so I wouldn't be too optimistic about getting a response. And even then it's quite likely that the original author considers xxd finished and would be reluctant to accept patches for it anyway. On top of all that the hard part of this work (cross-platform terminal colours) had already been done for the author, so the implementation was probably far easier than adding colour output to xxd would have been.

xxd is distributed with Vim.

I've never thought of xxd as being anything but a "Vim thing".

That it had its own history (1990-1998) before being pulled into Vim is a TIL for me.

Here you go:

https://github.com/vim/vim/tree/master/src/xxd

There might still be other versions of this out there, but I suspect most OS distros pick up xxd by way of packaging Vim.

So if you work on some other xxd, you're probably in a dead fork.

The man page is also from Vim:

https://github.com/vim/vim/blob/master/runtime/doc/xxd.1

My first patch to xxd, if I were to work on it, would be to fix the man page to indicate clearly that it's the xxd bundled with Vim.

Cross-platform terminal coloring was solved in the 1980s with termcap and then terminfo, for every terminal that's even come close to seeing mainstream use and which had colors in the first place. The libraries are part of the ncurses library and are shipped with every OS this stuff would build on to begin with.

This also solves the problem of moving the cursor and drawing a screen in general.

Eh, A lot of modern terminal emulators don't seem to bother providing termcap/info entries, or setting their own $TERM variables. In reality, most code just fires off ANSI sequences and hopes for the best. Looking quickly at the source for Hexyl, I think that's what the ansi_term library it uses does.

If anything, I've found doing this works better then trying to muck around with ncurses, which often gets actively mislead by incorrect terminfo entries.

ncurses wins once you use terminals beyond xterm.

Aren't termcap and terminfo linux (or maybe unix) only?

Both of them long predate Linux. They're definitely Unix-flavored, but so's the Berkeley sockets library, and that's available everywhere, too. Ultimately, they're a library which is packaged with a database, and nothing about them is very system-specific except the terminal information in the database.

https://en.wikipedia.org/wiki/Terminfo

termcap was written by Bill Joy in 1978. terminfo dates back to 1982.

termcap is supported on FreeBSD, at the least.

termcap/terminfo styling is limited to features like underline, bold and reverse. No coloring, per se.

"man terminfo | grep color" shows that pretty clearly to not be the case. There's plenty of codes for setting colors.

It's entirely possible termcap and terminfo have been allowing applications to color their output for longer than you've been alive.

The downvotes prove how much HN hates history, I suppose.

Because the author wanted to do his own, personal thing?

I get the idea behind your question, but it irks me a bit since it implies a sort of responsibility to contribute to an existing piece of software. This is a net positive of course, but the beauty of open source is the freedom to work on the things you want to work on.

It's illegible in my terminal. Not a fan of the trend to hardcoded unicorn vomit.

I have to admit, my first question in mind was how to disable colors because I do not use syntax highlighting at all.

but if you want to disable colours in this why not use hexdump or xxd :D . it's like the only feature it adds to standard hexdump tools

I'm also not a fan of the colouring, especially in this application, because when you're looking at a hexdump chances are you don't care about ASCII or whitespace --- and it's not as if you couldn't tell whether something is in the ASCII range, given the character representation in the right column anyway.

The border lines don't help much either and seem more like decoration; addresses to the left and an indexing header on the top, like the traditional "canonical" hexdump format, would be far more useful.

How can you tell the difference between an unprintable character and whatever encodes them (I've most often seen '.'), in a single character cell, without color?

Me neither.

I did use it religiously for a long, long time; then tried without for a week and never went back.

It's not like telling the difference between string literals and keywords was ever a major issue for me. I guess it could help short term when learning a new language, but I'm pretty sure it slows down overall progress.

How does it slow down progress?

For me it doesn't. It's a quick way to see that I made a typo when a keyword doesn't turn the right color, or that I closed a strong with the wrong quote Mark.

I find it's a bit like navigating using GPS, once I get there I still have no clue because I was mostly acting on cues.

Slow compiles have the same effect for me, I get pushed out of flow and into reactive mode.

The only way to write good code is to be proactive, and any features that interfere with that process are worse than whatever "problems" they "solve".

Liked that though the boxes seem to be a distraction. Perhaps they could use the dim ansi code or be turned off.

Just looked at manpages on someone else's account with no colour highlighting, definitely missed it.