To clarify, something like
$ hexdump -C -s 0x1b -n 16 /dev/urandom
0000001b 6c f3 fe 4e 4c 9d aa 75 b6 d6 b4 89 05 20 e5 46 |l..NL..u.....
.F|
0000002b
$
takes the trailing `b' of `0x1b' to be part of the hex number giving
decimal 27, as shown by the offset column in the output, whereas I may
have wanted 0x1b to be one block (b) of 512 bytes in.
If I use decimal instead of hex then the problem doesn't arise because
strtol(3) knows `b' isn't a valid decimal digit and doesn't consume it,
leaving it for hexdump to use as a size indicator. hexdump -s 1b.
That hex offsets and the `b' suffix can't be mixed is annoying because
examining hard disc and filesystem images often results in hex numbers
in units of sectors (512 bytes).
--
hexdump's -s option can't spot a trailing `b' for blocks with a hex offset
https://bugs.launchpad.net/bugs/229988
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
