http://www.perlmonks.org?node_id=1012753


in reply to Re: unpack() removing data
in thread unpack() removing data

The strange part is that gives me the results I'm expecting ( byte not stripped out ). It's NOT reading the binary results from the temp.bin file which is causing me problems.

Replies are listed 'Best First'.
Re^3: unpack() removing data
by BrowserUk (Patriarch) on Jan 11, 2013 at 09:58 UTC

    Without sample data (ie. the output from sglogs which I have no knowledge of), I cannot guess further.

    But I bet the root cause is the reading or writing of binary values using functions designed for delimited text.


    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
Re^3: unpack() removing data
by quester (Vicar) on Jan 11, 2013 at 07:09 UTC

    On my system (Fedora 17, perl v5.14.3) it strips out hex 0D (CR) in both cases. Handling of line terminators is documented as being system-dependent, though. Without knowing exactly which character being deleted (and the characters before and after it) and what flavor of system you are running on it's hard to guess what the problem might be. You might try this and see if the two dumps are different; if they are you can start looking at sg_logs rather than at your perl script...

    sg_logs --page=0x34,1 pd1 -H -r > temp.bin od -x temp.bin | head sg_logs --page=0x34,1 pd1 -H -r | od -x | head
      the system is win7 strawberry perl 5.12.3.0. it does look like the byte being removed is 0x0d consistently. i'll explore that a bit. this is a good lead. thanks!