I think it would be interesting to try and maintain some level of compatibility with xxd. I recently came across this when following a blog post, trying to use hexyl instead of xxd.
The most obvious thing would be to introduce (yet another) alias for --length/--bytes, i.e. -l in addition to -n and -c.
Another cool feature of xxd is the -groupsize option. This is already being discussed in #104.
What other flags/options could we try to support or try to provide aliases for?
What we're definitely not going to support is long single-dash options like -groupsize. Instead, we are always going to keep a style where long options come with two dashes --groupsize.
By the way, one thing that we already do better:
Even though xxd itself doesn't support hexadecimal notation […]
So instead of xxd -s $((0x2118)) ./hello we can simply say hexyl -s 0x2118 ./hello.
Note: we already try to be (partially) compatible with hexdump.
The text was updated successfully, but these errors were encountered:
sharkdp
changed the title
Compatibility with xxd?
(Partial) compatibility with xxd?
Oct 31, 2020
I think it would be interesting to try and maintain some level of compatibility with
xxd. I recently came across this when following a blog post, trying to usehexylinstead ofxxd.--length/--bytes, i.e.-lin addition to-nand-c.xxdis the-groupsizeoption. This is already being discussed in #104.What we're definitely not going to support is long single-dash options like
-groupsize. Instead, we are always going to keep a style where long options come with two dashes--groupsize.By the way, one thing that we already do better:
So instead of
xxd -s $((0x2118)) ./hellowe can simply sayhexyl -s 0x2118 ./hello.Note: we already try to be (partially) compatible with
hexdump.The text was updated successfully, but these errors were encountered: