You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the past few weeks, I've been working with odd formats that make use of Pascal strings in the encoding. And working with hex numbers while also having to count out distance and such is cumbersome, especially with changing values and if you don't have a website/calculator/piece of paper/another shell at hand. Normal hexdump supports specifying a custom format (specifying which is egregiously complex...), but thanks to this answer on StackOverflow, there is a pre-cooked way to gather single-byte decimal (which isn't exposed on hexdump's normal interface as a shortcut, unlike single-digit octal and two-digit decimal...) dumps together with the characters:
(However, this format lacks the separator in the middle for the characters, and also, just like hexdump's usual, lacks colours.)
One problem with the above format is "negative numbers". This is very like platform specific, but char 128 (\PAD) is represented as -128 in the output of hexdump. While this kind of ties into #104, it would be nicer if the decimal could be specified to always be positive (it also breaks the output formatting because of the sometimes-appearing - signs), i.e. between 0 and 255.
So what I'd like to request is a slight formatting change, instead of columns of 2, columns of 3 digits, which each show the decimal value of the byte at hand. The rest should remain the same, together with the colouring, etc. On my system, conventional hexdump exposes the following shortcuts:
$ echo "sharkdp/hexyl" | hexdump -b
0000000 163 150 141 162 153 144 160 057 150 145 170 171 154 012
000000e
$ echo "sharkdp/hexyl" | hexdump -c
0000000 s h a r k d p / h e x y l \n
000000e
$ echo "sharkdp/hexyl" | hexdump -d
0000000 26739 29281 25707 12144 25960 31096 02668
000000e
$ echo "sharkdp/hexyl" | hexdump -o
0000000 064163 071141 062153 027560 062550 074570 005154
000000e
$ echo "sharkdp/hexyl" | hexdump -x
0000000 6873 7261 646b 2f70 6568 7978 0a6c
000000e
Sadly, -d means two-byte decimal (but at least unsigned!), so a better shortcut character should be used, if #104 ever wants to be implemented in an invocation-compatible way. (--word-size=2 --decimal --unsiged --little-endian would be the mapping of hexdump's -d.)
The text was updated successfully, but these errors were encountered:
In the past few weeks, I've been working with odd formats that make use of Pascal strings in the encoding. And working with hex numbers while also having to count out distance and such is cumbersome, especially with changing values and if you don't have a website/calculator/piece of paper/another shell at hand. Normal
hexdump
supports specifying a custom format (specifying which is egregiously complex...), but thanks to this answer on StackOverflow, there is a pre-cooked way to gather single-byte decimal (which isn't exposed onhexdump
's normal interface as a shortcut, unlike single-digit octal and two-digit decimal...) dumps together with the characters:(However, this format lacks the separator in the middle for the characters, and also, just like
hexdump
's usual, lacks colours.)One problem with the above format is "negative numbers". This is very like platform specific, but
char 128
(\PAD
) is represented as-128
in the output ofhexdump
. While this kind of ties into #104, it would be nicer if the decimal could be specified to always be positive (it also breaks the output formatting because of the sometimes-appearing-
signs), i.e. between0
and255
.So what I'd like to request is a slight formatting change, instead of columns of 2, columns of 3 digits, which each show the decimal value of the byte at hand. The rest should remain the same, together with the colouring, etc. On my system, conventional
hexdump
exposes the following shortcuts:Sadly,
-d
means two-byte decimal (but at least unsigned!), so a better shortcut character should be used, if #104 ever wants to be implemented in an invocation-compatible way. (--word-size=2 --decimal --unsiged --little-endian
would be the mapping ofhexdump
's-d
.)The text was updated successfully, but these errors were encountered: