I guess my last message was a tldr, but if you look at the second half it's not just a matter of byte order.
The bytes are completely wrong. As far as I can tell there is just random garbage in 2 of the fields. As it happens, I can write this snippet just to handle output from the particular application because that's all it needs. Otherwise I guess I could do what most image programs do - assume that the header is completely corrupt and try 1000 ways to read the file. AJ ONeal On Fri, Oct 29, 2010 at 1:50 PM, Stuart Jansen <[email protected]> wrote: > On Thu, 2010-10-28 at 18:22 -0600, AJ ONeal wrote: > > > hexdump exposes the magic number as 42 4D > > instead I see 4D 42 > > but if I make it two chars rather than one short I do get 42 4D > > A quick test reveals that hexdump is "helpfully" swapping bytes. One fix > is to add the -C option. > > $ echo 0123456789 | hexdump > 0000000 3130 3332 3534 3736 3938 000a > 000000b > > $ echo 0123456789 | hexdump -C > 00000000 30 31 32 33 34 35 36 37 38 39 0a |0123456789.| > 0000000b > > > -------------------- > BYU Unix Users Group > http://uug.byu.edu/ > > The opinions expressed in this message are the responsibility of their > author. They are not endorsed by BYU, the BYU CS Department or BYU-UUG. > ___________________________________________________________________ > List Info (unsubscribe here): http://uug.byu.edu/mailman/listinfo/uug-list >
-------------------- BYU Unix Users Group http://uug.byu.edu/ The opinions expressed in this message are the responsibility of their author. They are not endorsed by BYU, the BYU CS Department or BYU-UUG. ___________________________________________________________________ List Info (unsubscribe here): http://uug.byu.edu/mailman/listinfo/uug-list
