hexdump's -s option can't spot a trailing `b' for blocks with a hex offset

[Ralph Corderoy]

Binary package hint: bsdmainutils

Ubuntu 8.04, bsdmainutils 6.1.10ubuntu2.

hexdump(1) suggests `-s offset' can be used to skip offset amount of data. offset can be base 10, 8, or 16, depending on its prefix. A trailing `b', `k', or `m' can be used to specify units. I can't specify a hex offset with a trailing `b' for 512-byte block units; the `b' is consumed by strtol(3) as part of the hex number in hexsyntax.c.

The syntax should be changed. It's currently ambiguous and the program can't know the user's intention. The `b' suffix is useful for dealing with disc images where units are often 512-byte blocks.

[Ralph Corderoy (ralph-inputplus)]

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).

[John Vivirito (gnomefreak)]

I am able to confirm this on Hardy chroot and intrepid system install.