jesuashok has asked for the wisdom of the Perl Monks concerning the following question:
|
---|
Replies are listed 'Best First'. | |
---|---|
Re: Data::Dumper issue
by Joost (Canon) on Jun 07, 2006 at 17:07 UTC | |
I have encountered a situation where the output of Data::Dumper cannot be incorporated in a script to restore the original data, specifically where a string contains the sequence ^M^J and $Useqq is unset. (Note: this arises in my work because I have packed numbers in a large data structure, and on a few occasions the packed sequence happens to include ^M^J as a subsequence.)This should "just work", but you should use binmode() on a filehandle that you intend to read/write binary data to.
The issue arises because perl seems to have a "friendly" way to handle DOS files on Unix platforms. My guess is that at a really early stage of reading the script file, ^M^J is translated to ^J, presumably before perl is even parsing the input.Perl does no such thing (edit: on unix). However, writing "\n" on a non-binmode()d filehandle on windows will write a return/linefeed pair and vice versa on reads. On (most?) unixes, there is no difference between binary files and text files.
Obviously, it is ignoring the single quotes in this example, since the single quotes should suppress any interpretation of the input. (Note that I realize this is generally a desirable behaviour, so I think the bug is with Data::Dumper, not with how files are read.)Your example simply fails to demonstrate anything like that since you're not reading/writing any files. The output of Data::Dumper is correct, as me and others have already pointed out to you.
Note also that, as my script shows, this is not a problem when we use eval on the output of dumpSo Data::Dumper is in fact working correctly. ..., but only when the code is saved to a file a compiled back from the file. (Unfortunately for me, I wish to save the dump to a file for frequent reuse, so that doesn't help me much...) And you're not showing us how you're reading/writing that file. I strongly suspect the error is somewhere in the code you're not showing.
| [reply] |
Re: Data::Dumper issue = PLAGIARISM
by liverpole (Monsignor) on Oct 16, 2006 at 14:12 UTC | |
And by "EXACT", I mean word-for-word the same:
For more information about jesuashok's habit of wholesale "borrowing" of material from other websites, please refer to this node. s''(q.S:$/9=(T1';s;(..)(..);$..=substr+crypt($1,$2),2,3;eg;print$..$/ | [reply] [d/l] |
Re: Data::Dumper issue
by Joost (Canon) on Jun 07, 2006 at 15:37 UTC | |
| [reply] |
| |
Re: Data::Dumper issue
by liverpole (Monsignor) on Jun 07, 2006 at 15:42 UTC | |
It seems, that does not work as expected. I guess the $64,000 question is "how did you *expect* it to work?" I get the same thing when I run it, but it seems that assigning Useqq to a nonzero value will cause whitespace to be represented differently (as well as "unsafe" characters). And that seems to be exactly what's happening, no? s''(q.S:$/9=(T1';s;(..)(..);$..=substr+crypt($1,$2),2,3;eg;print$..$/ | [reply] |
| |
Re: Data::Dumper issue
by runrig (Abbot) on Jun 07, 2006 at 23:48 UTC | |
| [reply] |