When using od with output formats of 1 or 2 bytes, the printed
output
can be wrong, particularly--but not exclusively--with non-printing
characters. Specifically, the output is sometimes printed as an
asterisk
('*') instead of the regular output--the whole line being affected. For
example, on Cygwin (the most current 1.5.25-15):
$ od --version
od (GNU coreutils) 6.10
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by Jim Meyering.
$ print -n '\0112\0106\0111\0106\0000\0001\0001\0000\0000\0001' | od
-toC -w1
0000000 112
0000001 106
0000002 111
0000003 106
0000004 000
0000005 001
*
0000007 000
*
0000011 001
0000012
I get an identical result on RHEL3 with od version 4.5.3. (I'm using
ksh,
so ksh print is in effect for this example. On Linux echo -n -e can
also
be used. My specific Linux version is Red Hat Linux 3.2.3-59, kernel
2.4.21-57.EL.) In fact, in all cases that I checked on both, the
results
are identical for my two computers.
The problem also happens if the -w1 option is left off, but it does
not occur in the same places. For example (in which you can see that
the
short example above is a subset from the end of the first line):
$ od -tx1 -Ax exp.jpg | head -10
000000 ff d8 ff e0 00 10 4a 46 49 46 00 01 01 00 00 01
000010 00 01 00 00 ff db 00 84 00 08 06 06 07 06 05 08
000020 07 07 07 09 09 08 0a 0c 14 0d 0c 0b 0b 0c 19 12
000030 13 0f 14 1d 1a 1f 1e 1d 1a 1c 1c 20 24 2e 27 20
000040 22 2c 23 1c 1c 28 37 29 2c 30 31 34 34 34 1f 27
000050 39 3d 38 32 3c 2e 33 34 32 01 09 09 09 0c 0b 0c
000060 18 0d 0d 18 32 21 1c 21 32 32 32 32 32 32 32 32
000070 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32
*
000090 32 32 32 32 32 32 32 32 32 32 ff c0 00 0b 08 01
The line that is omitted is all 0x32 (a repeat of line 0x70). (Every
JPEG file that I tried demonstrates the problem, by the way. For that
matter, every file that is long enough demonstrates it.)
The problem happens with -to1, -toC, -tx1, -txC, -to2, and -tx2.
The output line that gets corrupted is the same whether o or x is
chosen.
It happens more often with respect to byte count when -w1 is used.
It does happen with plain text files, too, but not quite as often.
Because I have seen identical results with two different versions
on
two different OSs, I am sending this to coreutils rather than to
either of the two OS owners, as it sure seems to not be OS related.
Craig Howland
_______________________________________________
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
