I admit, my first thought on seeing the title was "What's wrong with xxd?"
This is nice! I like the colorization a lot -- it's like with source code, you don't realize how much you rely on the colors until you get a new computer and need to download syntax definitions for your editor again. Only feature I really think is missing is line numbers.
> 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).
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.
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.
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.
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.
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.
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.
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?
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.
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.
One ludicrous nitpick: the logo doesn't show anything hexyl, that's 1,2,3,5-tetramethylbenzene. If it was a functional group, it might be 3,4,5-trimethylbenzyl or something like that.
.. which is apparently also called "Hexyl". Granted, I was just looking for a short word that starts with "Hex" and I was never good at organic chemistry :-)
xxd `which hexyl` > /dev/null 0.12s user 0.09s system 99% cpu 0.219 total
hexdump `which hexyl` > /dev/null 0.19s user 0.05s system 91% cpu 0.256 total
hexyl `which hexyl` > /dev/null 1.69s user 0.39s system 95% cpu 2.175 total
... and I have already used hyperfine to benchmark hexyl as well :-)
Yes, it's a shame. But I don't think there is too much we can do about it. We have to print much more to the console due to the ANSI escape codes and we also have to do some conditional checks ON EACH BYTE in order to colorize them correctly. Surely there are some ways to speed everything up a little bit, but in the end I don't think its a real issue. Nobody is going to look at 1MB dumps in a console hex viewer (that's 60,000 lines of output!) without restricting it to some region. And if somebody really wants to, he can probably spare 1.5 seconds to wait for the output :-)
We have to print much more to the console due to the ANSI escape codes and we also have to do some conditional checks ON EACH BYTE in order to colorize them correctly.
A few extra comparisons and output for each byte shouldn't be that much slower; fortunately the function of this program is extremely well-defined, so we can calculate some estimates. Assuming a billion instructions per second, taking ~1.5s to hexdump ~1 million bytes means each byte is consuming ~1500 instructions to process. In reality the time above is probably on a faster CPU, so that number maybe 2-3x more. That is a shockingly high number just to split a byte into two nybbles (expected to be 1-3 instructions), convert the nybbles into ASCII (~3 instructions), and decide on the colour (let's be very generous and say ~100 instructions.)
The fact that the binary itself is >1MB is also rather surprising, especially given that the source (not familiar with Rust, but still understandable) seems quite small and straightforward.
Rust binaries can be large because unlike C, the standard library is statically linked, as well as jemalloc. Jemalloc will no longer be the default as of the next release, so that will shave off ~300k...
The system malloc implementation. Users who want to use jemalloc have to opt in, but doing so is relatively easy (using the jemallocator crate from crates.io).
Did rust become less dependent on allocator performance, or did system allocators improve enough? IIRC glibc malloc has improved a lot over the last few years, particularly for multithreaded use, but I don't know about windows / macOS.
So, long ago, Rust actually had a large, Erlang-like runtime. So jemalloc was used. Over time, we shed more and more of this runtime, but jemalloc stayed. We didn't have a pluggable allocator story, and so we couldn't really remove it without causing a regression for people who do need jemalloc. Additionally, jemalloc was already removed on some platforms for a long time; Windows has been shipping the system allocator for as long as I can remember.
So, now that we have a stable way to let you use jemalloc, the right default for a systems language is to use the system allocator. If jemalloc makes sense for you, you can still use it, but if not, you save a non-significant amount of binary size, which matters to a lot of people. See the parent I originally replied to for an example of a very common response when looking at Rust binary sizes.
It's really more about letting you choose the tradeoff than it is about specific improvements between the allocators.
Most of the improvement came from not using printf, fputs, and putchar in favour of operating directly on an array for the line that can be fwritten in one call.
It takes a second to compute all that color.
Nice tool though - but what I would really like to see is a --color argument added to xxd as well, as I'll probably forget about hexyl down the line and start looking for xxd again (which is conveniently already installed on most *nix systems).
the author appears to be a true rust master, he wrote quite a few neat programs in rust, very impressive and that actually got me interested in rust lang
One of the problems with vim+xxd (and many other hex editors) is that it loads the entire file, so you can't easily use it to look at large files (archives, disk images, etc).
Many moons ago I wrote a very bare bones ncurses hex viewer/editor, after not really being able to find one that fit my needs. I still use it pretty regularly:
https://github.com/quo/hex.py
The colorized output is a nice incremental improvement on xxd. And, I think that it's nice that the README doesn't unnecessarily emphasize that it's written in Rust.
Slightly off tangent: One tool I have used to dump data (and more) is cxmon. A very nice monitor if one grew up using monitor cartridges on C64, Amiga etc:
Cool tool :) having a hex dumper that understood UTF-8 and dumped the characters as one of the columns would be awesome too. These days, ASCII is a small subset of strings.
Sorry to ask, but what is he use case for a hex viewer like this? What are the kinds of projects you might be working on when you use something like this?
You come across an undescript binary. It might be a jpeg with an altered extension, malware or basically anything. You open it in a hex viewer and try to gather some info.
Your lab manager goes "hey, can you generate these proprietary binary files (currently made with a horrible gui) to control this robot programmatically".
Uh, vim doesn't open binary files very well, and the initial goal is to just display them to figure out how they work not to edit them.
Afterwards you will probably want to run experiments with a hex editor, but I found that xxd + vim was better for reading then doing so directly in a hex editor at the time. If I did it again I'd likely start with this because of the color.
This isn't very common, but I was trying to build a common CLI tool in the browser to use in an internal application at work. I compared output from my implementation with the CLI tool until I got to feature parity (and to clear up confusing things in the spec/source code).
For other things, I've used it for examining network packets (binary protocols), mystery files, and proprietary data formats. I've also used a hex editor to hack executables (most notably hacking in a dark theme into Unity3D).
One (of many) uses I used xxd for: viewing a byte stream that is supposed to be utf-8 text, but the non-ascii characters in the file are not displaying properly. Hex viewers will let you see exactly what bytes are present, without interpretation. As for the utf-8 stream, it turned out to have been double encoded into utf-8.
So i have been working on an embedded project lately where i had to export the framebuffer to an sd Card. I used a raw Format first (netppm) and had to use vim in hex Mode to validate the header. So this is really neat. I was looking for an padding option in the readme but i guess i ll have to install it later
If I can make a suggestion - I don't mind the program being slow because of all the logic - how would it be if you didn't give special status to ascii but instead tried to intelligently assume a string encoding for strings and accordingly colored "binary" vs "text" (utf-8, utf-16)
This is nice! I like the colorization a lot -- it's like with source code, you don't realize how much you rely on the colors until you get a new computer and need to download syntax definitions for your editor again. Only feature I really think is missing is line numbers.
Nicely done!